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

Infra-Webcam Mod Part 1.

Due to a recent break-in near at our apartments, the whole security infrastructure went through an overhaul. Going through all the new features, I came across one that caught my eye, Night-Vision Security Cameras. Upon further investigation, I found these were actually Infrared cameras.

The cameras themselves looked like webcams dotted with red LEDs. Now, I had seen them before but never wondered their purpose or capability. A simple Google search uncovered a ton of info and the part that totally took me by surprise was the fact that these could be engineered at home using simple everyday camera hardware.

Now, I'm not gonna write down a tutorial or go much in depth but will give some insight on how I made mine.

The idea is simple. A normal camera has 3 components, the Lens, The IR filter and the CCD chip. All one has to do is to remove the IR filter and replace it with a "Visible Light filter" (Hint: Kodak).

Anyway, below are a few pics I took while disassembling and modding.

The Camera (Source: Local flea market, Vendor: PC-Touch)

The PCB with the Lens, IR FLTR, CCD.

IR Filter (Note to self: Next time take the picture before breaking the thing :-P)

CCD Chip (Lens, IR FLTR removed)

 Camera Lens with the light filter (Exposed camera film[Even Gradient])

Reassembled Module

Results in the next post.

Update[1/2/2013]: Damn! the drivers are 32 bit. Lets see if Linux does the job.

Old Cell Phones == treasure;

I guess many people don't realize before dumping their old phones that they are also throwing away a treasure trove of micro hardware that can be extracted and used in multiple DIY projects. I don't blame them as most people don't even know how does the vibration in their phones work.

So recently while going through some old 2006< cellphones, I decided to salvage such components. I recovered some really neat gems:

• Micromotors [Both types: External and Sealed]
• Mics
• Speakers
• 2MP camera modules
• LCDs [Color 64K & 256K 160ppi & B/W 100ppi]
• Micro DC-in female jacks

Now to think of some things I could do with them!?? Bristlebots anyone ;-)

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

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 :)

Hardinfo: System Profiler and BenchMark Tool

Some time back, I did a blog post on "Sysinfo" which at that time was my choice of system information extraction utility. After my switch to Fedora, I failed to find a port of Sysinfo for that platform and attempts at compiling always led to issues. Therefore after some searching I found 'lshw' which seemed a good choice but again was a tad too much in terms of information.

So after a bit more search, I discovered "Hardinfo" (http://hardinfo.berlios.de/HomePage) which seemed to be a very nice and well done utility to get system information. It also seemed much more detailed than Sysinfo and very user friendly. HardInfo also has inbuilt benchmarking as an extra feature. Overall a very nice tool.

To install under Fedora, just do:

su
yum install hardinfo

Then it can be found under: Applications >> System Tools >> System Profiler and Benchmark

FBO, Stencil and the 'Blur Plugin' in Compiz Fusion.

For the past 1 year I have been endlessly trying to get the blur plugin to work in my laptop. I'm among the many people who suffer with this problem. Here's what I have understood till now after considerable amount of research.

I have an Intel GMA 950 card which comes as a default on the i945 chipset. In previous versions of CF i.e. <.7 builds, the plugin never worked due to a bug in the Mesa driver namely in the fragment_environment_variables section. Now in the new build (post .7), a new plugin with the name of 'Workarounds' attempted to provide a fix with the name 'AIGLX fragment program fix'. This helped in many ways by enabling effects like Water, Reflections to work properly on IGMA cards but the 'blur' system still had a problem.

Enabling the plugin caused the Mesa driver to kick compiz in software mode and effects fell to less than 1 FPS. Also, only the 4xBilinear filter(among the Gaussian & Mipmap filters) worked because a lack of FBOs (Frame Buffer Objects). Another small thing I noticed that while running compiz via terminal, is that a message 'Warn: No stencil buffer. Region based blur disabled', shows a faulty implementation of Mesa thus creating the problem in blur. Blur requires the stencil buffer system to work.

Many attempts are underway to port implementations such as 'Fake Blur' and 'BlurFx' into CF from the old Beryl system. Also, users are still sitting patient for the fixes in Mesa to come. Till then, no blur for IGMA users.