Showing posts with label coretemp. Show all posts
Showing posts with label coretemp. Show all posts

Sunday, February 10, 2013

Linux in 2013, systemd, kernel regressions etc etc...

It has been a very busy time for me, exams on one side and setting up Arch all over again on the other. Somehow I got upto 70% of the work done reinstalling, configuring, rewritting and theming but thankfully the worst is out of the way. I know that because before I reinstalled Arch, I assumed a lot of things about the procedure from earlier experience but the reality was close to shocking, see below.

1. Arch installer removed, all steps are to be done by the user.
2. Bye sysvinit! Hello systemd
3. Kernel Power Regressions. !!
4. HDD APM Issue. !!
5. Openbox updated to 3.5
6. Kernel Ver. @ 3.7.6
7. Since I had newer hardware with dual GPUs [Hybrid Graphics/Optimus], I had to rewrite conky and many scripts due to many low level changes.

Now Im not saying that all of this was bad, actually upgrades like systemd were much of a welcome, anyway what follows is a rundown of each and what I did to counter/resolve the issues.

1. Not much of an issue actually, to be honest, I liked the fact that the installer now required the user to customize manually. Helps in the optimization of the system also as a secondary bonus, the packages installed are always the latest since the new installer "pacstrap" downloaded the latest package versions as compared to installing directly from the Live Media.

2. This was a big surprise, whatever I knew about the original rc.conf sysvinit boot system had to be washed and relearnt with systemd in mind. Mind you, systemd is a boon! Bootup times have been slashed due to the efficient parallelization implemented which contrasts from the original init sequential boot proccess. Also systemd allowed for a much neater boot process modification and the entire start|stop sequence is much cleaner. Although it takes a while to get used to but once you do, creating your own service/tmpfiles becomes a breeze. Also syslogd is now replaced with a journel which can be accessed through the systemctl command. Actually all one needs to use is the systemctl command!

3. These "issues" are actually fixed in the 3.8.x RC versions which are yet to be tested and marked stable but we will get there. The issues Im talking about affect the sandybridge (and possibly ivy too!) line of CPUs. CPU frequency scaling gets locked at maximum frequency w/o turbo boost (Thank god!). In my case (2670QM) the scaling clocks reported to be the lowest clock possible: 800 MHz, but a look at the current clocks proved that they were actually stuck at 2.2 GHZ. Also, on the integrated GPU end, RC6 (powersaving) state was not being initialized. What really frustrated me further that temperatures were 10-15 degrees (Celsius)  higher than in Windows. This tends to happen randomly per boot and will be fixed once 3.8 is available as stable. Tip: If you cant wait, check the links at the end of the post for RC(Release Candidate) versions of the kernel.

  #] cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
 800000

 #] cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
 2201000


4. This was the most annoying/frustrating issue I have ever had. Not because it was difficult to fix but because of the everlasting effect it may have had on my HDD. Before I say more, understand that its not really Linux's fault, read on. Long story short,  2.5" HDDs implement shady power saving mechanisms such as head parking and spinning down the spindle motor during an I/O idle session. Furthermore the smart brass at WDC decided to choose power saving over HDD lifespan. How they achieved this was by implementing something called intellipark, which essentially parks the head whenever it senses that I/O is idling. Sometimes this is done in less than 8 seconds. What this results in is a constant "clicking" sound from the HDD and the slow but eventual degradation in head quality which could lead to HDD failure. If that is not enough, the slowdown of the spindle motor puts pressure on it because to spin up the motor for an I/O active session it requires throwing in more power and not to mention stresses the motor further (Newton's first law!).

12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       455
193 Load_Cycle_Count        0x0032   155   155   000    Old_age   Always       -       136465

Checking SMART data on the HDD showed that the current LOAD_CYCLE_COUNT (Number of parks) had jumped to 136465 in less than a year. To put this in perspective, an average 2.5" HDD has a lifetime of 300000 - 600000 parks. Way to go WDC!

 I would also like to add that a similar but slightly less annoying effect was also visible when running Windows 7. Thankfully Linux has a tool [hdparm] which allows modifying many variables on the HDD directly such as the APM(Advanced Power Management) value. My original value was 96, which then I changed to 254 to basically kill all possible forms of APM. Did it work?

Yes! :-)

5. Not new and also not much of an issue, openbox 3.4 config is a drop in replacement for 3.5.

6. Kernel is currently at 3.7.6, nice and fast with major fixes but with the power regressions.

7. As previously mentioned in an older post, this was somewhat of a new laptop, modifying old scripts/configs took some time, had to scale conky config and other scripts to take into i7's quad cores plus inclusion of NVIDIA GPU temperature monitoring thanks to the free nouveau driver which enabled basic power management.

Optimus is still not a fully functional componenet in Linux but thanks to projects such as bumblebee, enabling hybrid graphics support was relatively easy.

So thats pretty much it, Im looking forward to checking out how tools such as Metasploit, Nmap etc have improved.

Any questions/comments... insults??

Ref:

Kernel Power Regressions: 
: https://bbs.archlinux.org/viewtopic.php?id=150743  //RC Versions in this thread
: https://wiki.archlinux.org/index.php/Intel_Graphics#Module-based_Powersaving_Options

HDD APM Issue: 
: https://bbs.archlinux.org/viewtopic.php?id=39258
: https://wiki.archlinux.org/index.php/Hdparm#Parking_your_hard_drive
: http://en.wikipedia.org/wiki/S.M.A.R.T.#ATA_S.M.A.R.T._attributes
: http://forums.anandtech.com/showthread.php?t=2085685

Systemd:
: https://wiki.archlinux.org/index.php/Systemd

Saturday, July 7, 2012

DIY cooling solution...

I recently bought a new notebook [my old machine was... well old... needed a well deserved retirement. Goodbye ProcyonMk2 you ol' girl! :-P], about 2 months ago. ASUS K53 series, specs are:

ProcyonMk3:
15.6 inch screen @ 1366x768 WLED screen
Intel 2670QM CPU [4 Core + HT = 8 Threads]
NVIDIA GT 540M GPU [2GB DDR3 VRAM] [Optimus Solution]
ASint 8GB DDR3 RAM
WDC 5400RPM 750GB HDD
USB2.0 x 2, USB3.0 x 1
Atheros b/g/n Wifi, Realtek Audio, BT3, Altec-Lansing Speakers, 6 Cell Battery.

Basically a pretty powerful system. I wouldn't attach an ULTRA tag [my way of rating notebooks: low, midrange, high, ultra] to it but would consider it to be a HIGH end machine [a first for me since i am used to owning low to mid-range systems]...

Anyway, considering a heatwave thats been plaguing the area where I live, a decent cooling solution had to be designed as my old cooling pad was busted with 2 of its fans burnt out.

So basically I had this old but totally unused 12 volt .3 amps [3.6 watts] DC chassis fan lying around which I had extracted from my desktop since the mobo didn't have a chassis fan socket. Using an old router adapter rated at 12volts .7 amps DC [No.1 rule in Electrical Engg: Voltage should be the same, Current should be equal or more], laptop packaging and some nice nifty tools, made my own DIY cooling pad.

It turned out pretty good considering its simplicity.

Pics attached [I'm too lazy to take detailed photos, if you don't understand the design, then leave a comment and I could help you out]:

Pic 1: Underside.

Pic 2: Upside.

End Result: Cool'n'Quiet system, 1 week's lunch money saved :-)

Update: Since this is a internal desktop chassis fan, it has a high dB level, bloody thing makes noise like a jet engine. Good thing my speakers damp it all out with music... ;-D

Sunday, March 13, 2011

Dell Studio 1535 cleaning/disassembly

The temperature sensors on procyon [My Dell Studio 1535] laptop were constantly hitting abnormal values recently. CPU kept on idling at around 60C, even after my previous post on the fix for lm_sensors configuration applied. So I knew that it was time I opened the girl up and do her some good'ol fashioned cleaning. So I borrowed a cam, took out my toolbox, acquired some Thermal Compound [Shin-Etsu Microsi's G-751 Thermal Paste (thanks Shray!)] from a good friend, added some Pink Floyd on my playlist and got to work. Here are a few pics of the internals for anyone's viewing pleasure since I could not find any decent teardown images of the same model on the web. Enjoy....

Backplate opened, Fan/Heat-sink assembly and processor removed  
Close-up of the first image.
The processor[Top]: Intel T5750 [2GHz, Socket-P, 2MBL2, 667 FSB]
The processor[Bottom]
Fan/Heat-sink assembly [Top]
Fan/Heat-sink assembly [Bottom] [Note the thermal pads for the MCH and GFX chips]
Fan/Heatsink assembly [Top, Fan Removed]
Fan/Heat-sink assembly [Bottom, Fan Removed]
Fan(Dirty) [Top]
Fan(Dirty) [Bottom]
Partially Cleaned Heat-sink Fins
ATI Mobility Radeon HD3450 256MB [The 2 chips on the left are the 128MBx2(Samsung) RAMDACs]
The Intel 965PM MCH
The Intel MCH and The Socket-P processor socket
The WPAN and WLAN[Broadcom BCM4312] cards.
Nanya 1GB DDR2 PC2-5300 @ 333 MHz x2 RAM Cards
The HDD [Western Digital WD3200BPVT] and The DVD drive
After a thorough cleaning and application of new thermal grease, the temps have dropped significantly by at least ~10C

End result: a cool and quiet system and a wholly satisfied conscience :)

Saturday, February 12, 2011

lm_sensors and Tjunction-max

Recently, the temperature values being reported by lm_sensors on my linux-lap were becoming a point of concern. The fan and heatsink assembly had just been cleaned a few days earlier but still lm_sensors reported my CPU was at ~70C while idling! Even considering the fact that I live in a hot part of the world, the values were too high for this time of the year and for an idling CPU. Checking the logs and a bit of web research revealed the culprit:

 └─>>$] dmesg | grep Tj
coretemp coretemp.0: TjMax is assumed as 100 C!
coretemp coretemp.1: TjMax is assumed as 100 C!


The Intel datasheet for a T5750 processor reports the designed Tj-max as 85C but gets detected as 100C, so lm_sensors was reporting the values with a +15C offset.

The bug seems to be in a recent git commit as explained in this thread: https://bbs.archlinux.org/viewtopic.php?pid=829902#p829902
Tjunction explained: http://www.techreaction.net/2009/10/14/guide-to-understanding-intel-temperatures/

UPDATE:
FIX: After discussing the issue with the devs on IRC, a small fix was suggested. Worked for me.

edit '/etc/sensors3.conf' and add the lines 
chip "coretemp-*"
    compute temp1 @-15,@+15
    compute temp2 @-15,@+15