Sabayon and microcodes

Hi everybody. This is the first of new kind of posts on my blog to help Sabayon users (and Linux users in general) to figure out how to fix some issue that I found on my way.

Today I want to share with you a little and simple guide to upgrade microcode in your Sabayon. 

But let's us start from the beginning.

What is microcode?

Intel and AMD microcodes are, citing Debian wiki:

Processor microcode is akin to processor firmware. The kernel is able to update the processor's firmware without the need to update it via a BIOS update.

so to guarantee the system stability and security, you need to keep your CPU microcodes updated.

How do I update my microcodes?

If you have an AMD CPU the microcode are shipped in the linux-firmware package, so you need to do nothing if you update frequently your system, but things get a bit more complex with an Intel CPU (like Haswell).

That is because Intel ucode need to be loaded before the kernel, so you have to do this using the following steps.

The first thing to do consist in generating the microcode cpio archive through iucode_tool (you can find it on sabayonlinux.org repo installing sys-apps/iucode_tool):

root# iucode_tool -S --write-earlyfw=/boot/early-ucode.cpio /lib/firmware/intel-ucode/*
iucode_tool: system has processor(s) with signature 0x000306c3
iucode_tool: Writing selected microcodes to: /boot/early-ucode.cpio

the file early-ucode.cpio should be placed in the initrd of your grub.cfg just before your kernel, but if you put it there directly every time you will regenerate your grub it will be removed.
So the best thing to do is edit the script used from grub-mkconfig.
The file you are looking for is /etc/grub.d/10_linux and you need to change the if clause here reported as follows.

140 141 142 143 144 145 146 147

if test -n "${initrd}" ; then # TRANSLATORS: ramdisk isn't identifier. Should be translated. message="$(gettext_printf "Loading initial ramdisk ...")" sed "s/^/$submenu_indentation/" << EOF echo '$(echo "$message" | grub_quote)' initrd ${rel_dirname}/early-ucode.cpio ${rel_dirname}/${initrd} EOF fi

(WARNING: line's numbers reported could change between GRUB 2 versions)
After this we have almost done, so you can simply rebuild your GRUB configuration using:

root# grub-mkconfig -o /boot/grub/grub.cfg

To check if you upgraded correctly your microcode dmesg should be like this:

root#  dmesg | grep microcode
[    6.430637] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x8
[    6.432835] microcode: CPU0 sig=0x306c3, pf=0x10, revision=0x8
[    6.434503] microcode: CPU0 updated to revision 0x1c, date = 2014-07-03
[    6.434511] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x8
[    6.436075] microcode: CPU1 sig=0x306c3, pf=0x10, revision=0x8
[    6.436958] microcode: CPU1 updated to revision 0x1c, date = 2014-07-03
[    6.436987] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x8
[    6.437015] microcode: CPU2 sig=0x306c3, pf=0x10, revision=0x8
[    6.437903] microcode: CPU2 updated to revision 0x1c, date = 2014-07-03
[    6.437912] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x8
[    6.437934] microcode: CPU3 sig=0x306c3, pf=0x10, revision=0x8
[    6.438823] microcode: CPU3 updated to revision 0x1c, date = 2014-07-03
[    6.438830] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x8
[    6.438864] microcode: CPU4 sig=0x306c3, pf=0x10, revision=0x8
[    6.439753] microcode: CPU4 updated to revision 0x1c, date = 2014-07-03
[    6.439760] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x8
[    6.439785] microcode: CPU5 sig=0x306c3, pf=0x10, revision=0x8
[    6.440669] microcode: CPU5 updated to revision 0x1c, date = 2014-07-03
[    6.440682] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x8
[    6.440707] microcode: CPU6 sig=0x306c3, pf=0x10, revision=0x8
[    6.441594] microcode: CPU6 updated to revision 0x1c, date = 2014-07-03
[    6.441601] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x8
[    6.441621] microcode: CPU7 sig=0x306c3, pf=0x10, revision=0x8
[    6.442512] microcode: CPU7 updated to revision 0x1c, date = 2014-07-03
[    6.442557] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

Remember to check frequently if you have the last microcode updated and don't forget to regenerate your cpio file.
And that's all folks, I hope this could help you to have a more stable system.

Sources:

• https://wiki.gentoo.org/wiki/Intel_microcode
• https://wiki.archlinux.org/index.php/Microcode

Calculating Angular Distance

Hi there followers, it's been a while from the last post but here I am again with fresh news.
Some weeks ago I was writing a program for an exam and I thought that sharing with you this code could be a good idea.
This because it's simple and can make easily understand how to fairly share the work between process with Open MPI.

Project Requirements

The goal is to develop a program written in C that calculate the angular distances between a group of stars, and than write as output the distribution of those distances so that could be plotted with Gnuplot.

The angular distance

Quoting Wikipedia:

In mathematics (in particular geometry and trigonometry) and all natural sciences (including astronomy, geophysics, etc.), the angular distance (angular separation, apparent distance, or apparent separation) between two point objects, as observed from a location different from either of these objects, is the size of the angle between the two directions originating from the observer and pointing towards these two objects.

So to calculate the position of two point i and j in the space we can use the following equation to get \( \theta \):

\[\theta_{ij} = arcos \left ( \frac {x_i x_j + y_i y_j + z_i z_j} {\sqrt{ (x_i^2+y_i^2+z_i^2) (x_j^2+y_j^2+z_j^2)} } \right ) \]

The result of this is a number between \( [0, \pi )  \).

Calculating the distribution

We know now how to calculate the angular distance between two points, but our goal is to get a distribution over a set of stars, and we get the parameter K to sample our set of values.

But our huge first problem is the number of operations required because defined \(n\) as the stars' number, we have \( \frac{n(n-1)} {2} \) distances.

So with a large amount of stars, we can easily reach billion of operations.

If we imagine the distances that we need to compute displaced as an upper triangular matrix, we need to split fairly the matrix's elements between our pool of processes.

The idea now is to transform the matrix in an array that concatenate every row of the matrix, in this way we can split the work but we lose a big information. How could we get back the row and the column simply from the index of the elements in the array?

Googling a lot I finally found the solution, even avoiding the two loops, using the following two formulas:

\[I_r =-{ \frac{(-2(n-1) - 1 + \sqrt{ 4 n (n-1) - 8 i - 7} )} {2}}\]

\[I_c = i - (n - 1) I_r + I_r \frac{I_r + 1} {2} + 1\] 

where \( I_r \) is our row index and  \( I_c \) is our column index.

We can now calculate our distribution of distance and this is the output for a set of 119613 stars and 1000 K intervals:

The output was generated in 151.870678 seconds with 8 processors on Intel i7 4700MQ quad core, a really good result.

The resulting speedup is plotted in the following image:

and this is the efficiency of the program:

We can see that with the Hyper Thread technology we obtain a little amount of speedup even if we go over the physical core number, but over 8 processes the efficiency goes down fast on a quad core.

So that's all folks, you can find this program and the example data-set on Github at the following link:

https://github.com/dgikiller/angular-distance

Please let me know if anything isn't clear or wrong, and I will try to correct it until it is. 

So if you linked this post, share, share, share!

The End is Near!

Hello everybody following, so we are near the finish line.

This is a really important week and we are under pressure because we need to complete all test by Monday.

Since August 11 I focused my work on developing all remaining part of the code and making some fixes at the code written, even some tests were developed.
The mojolicious routes were defined and we have all main functions working on the WebUi.
Always during the past week I planned to make some improvement introducing some widgets to monitor more sensors in our home, but for time reasons we need to postpone those improvements.

Now we need to work hard making some test and documentation of the code written to the best possible.
Documentation is the most important part to make easy understanding the code; in fact mudler changed a little my time schedule because we agreed that it is more important documentation of other parts.
We have even planned to externalize some part of the project as modules, because a more light project is certainly more maintainable than a self contained one.

A young project like this need to attract more developer and, if it is considered valid, could be used and developed from many other developer; this is achieved developing a good code with a good documentation!

I am very excited for the end of this experience but even a bit sad. This experience helped me to get in touch with the open source and this is really important and even fun.
So that's all folks, we need to work hard for the last week! 

Let's get some screenshots!!

Hello everybody, as the beginning of each week let's talk about project!
This is a very important week because time is running out so we need to complete pending tasks and get ready for August 18th, final term evaluation is coming!
So during past week I worked on WebUI and some little fixes on the code written.
About WebUI we reached a good point where layout is quite defined and the need is only a little tuning.
I tried to create a simple layout and usable layout, let me show you some screens!

This is the home page with tiles that represent our switch for the relays. 

Every tile can be in state on or off and we can understand this looking at opacity of tiles.

Tiles could be filtered by tag with the search form or by room with dropdown menu.

This is the login page to access at the admin zone.

As you can see, here we have the nodes Tables where we can add/delete/modify Nodes data and add/remove rooms.

Finally the GPIO table where we can manage our gpio.
So hope you like it, I know that is a bit "rude" but improvements will come soon.
For now that's all folks, and any kind comments are well accepted! See you ASAP still here!

A little Bug on Linux 3.16-rc6...

Hello everybody, here I am again to report an interesting bug that I saw just a little while ago.

The error was about GCC compiler that have produced a bugged kernel when compiling linux-3.16-rc.

We could find some detail in kernel mailing list ( "Random panic in load_balance() with 3.16-rc").

And here we could find a little extract of the mail:

...
movq $load_balance_mask, -136(%rbp) #, %sfp
subq $184, %rsp #,
movq (%rdx), %rax # sd_22(D)->parent, sd_parent
movl %edi, -144(%rbp) # this_cpu, %sfp
movl %ecx, -140(%rbp) # idle, %sfp
movq %r8, -200(%rbp) # continue_balancing, %sfp
movq %rax, -184(%rbp) # sd_parent, %sfp
movq -136(%rbp), %rax # %sfp, tcp_ptr__
#APP
add %gs:this_cpu_off, %rax # this_cpu_off, tcp_ptr__
#NO_APP
...

Note the contents of -136(%rbp). Seriously. That's an
_immediate_constant_ that the compiler is spilling.

Somebody needs to raise that as a gcc bug. Because it damn well is
some seriously crazy s**t.

However, that constant spilling part just counts as "too stupid to
live". The real bug is this:

movq $load_balance_mask, -136(%rbp) #, %sfp
subq $184, %rsp #,

where gcc creates the stack frame *after* having already used it tosave that constant *deep* below the stack frame.
The x86-64 ABI specifies a 128-byte red-zone under the stack pointer,and this is ok by that limit. It looks like it's illegal (136 > 128),but the fact is, we've had four "pushq"s to update %rsp since loading

the frame pointer, so it's just *barely* legal with the red-zoning.

Linus Torvalds reported this even on gcc-bugzilla.

Now seems that on rc7 introduced a workaround for buggy versions of gcc compiler.

So that's all folks, hope this will be fixed soon!

Javascript, Mojolicious and even more...

Hello everybody, here you are looking for some news and updates about the project!
Let's start talking about the WebUI that is taking some time to be developed but we already knew this and and we have taken into account.
Nevertheless, we are well on this because we have the major part of user UI, tiles are well structured and javascript should run fine too.
During this days, in fact, I spent some time on javascript function and tiles disposition so I changed the tile structure to have a more minimalistic feel of those.
A simple selector based on rooms was introduced and, with a little amount of time, tag search will be soon introduced.
For GSoC we planned to create a WebUI that looks like a TV remote control with a lot of toggle buttons and a page for those that would require more tweak options, but future enhancement we planned will introduce more and more functionalities.
We introduced the a tile class to have a structure for tiles that could be dispatched from mojolicious to the web page.
We even worked on some other parts of the code. Changes have been done on  SQLite DB too introducing a new entity (Pin) that will represent the real board's pins.
This was required by drivers of GPIO to cope the need of dual drivers requirements.
During this days the work will be focused on creating the admin panel and test the results.
Work on documentation and testing will go on too as fast as possible.
So that's all folks! See you soon and Good Work!

Creating some Documentation

Like every week beginning we are again here talking about our project.

This week I made a choice about task scheduling, deciding to work simultaneously on documentation's creation and WebUI design.

I agreed with my mentor this choice because I saw that documentation is an easy task that could be done during WebUI developing period even if this task was scheduled later in the timeline. Another reason is that if it passed a long period between the development of a module and its documentation, it would certainly be more difficult to remember the implementation choices and how it works.

So I started to creating a comprehensive documentation for the developed modules using perlpod.

But this didn't stop work on WebUI and his parts.

Now we have a structure for the tiles and his disposition in the page.

I chose isotope for buttons arrangement as suggested by mudler, than I created a page where we could find the button detail and a page where there are the grid view of this tiles.

I have planned to use some kind of images and a transitional background to understand if the GPIO is on or off.

To ensure the DB back end interoperability I will create a class that will provide me all info about the tiles and their status simply querying seamlessly the DB.

Now I must focus my work on creating an easy to use admin page for adding GPIO conf and more in an intuitive manner.

I hope that job will go on fast and we will collect a good results.

So for next news in a week folks. Stay tuned!