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! 

Ready for mockups

Like every week beginning here we are with some news about work!
In previous post I wrote about the UX design ad how much this is important for the user.
What we see is what we are left imprinted and a good interface is the best business card for the project.
So keeping this in my mind I planned to give a nice interface looking around and taking a cue from some UX that we all see frequently like Google+.
Google design guideline compel us to create more easy and minimalistic interfaces for our software, but even without sacrificing functionalities.
So I decided to start the project using Bootstrap as simple and ready-to-use framework to get responsive the WebUI.
Setting up bootstrap is simple but tweaking it not, especially if we want some particular design for our website.
My idea is to get an interface with a toolbar on the top that will contain all action for the webui (like MacOS interface), and a middle part were we could find some different tiles for every action.
In this part I will define a simple static layout for our Remote Controller, but in future (even after GSoC) I planned to introduce custom per user layout.
The big clue is the admin area that is really difficult to be simple and powerful but we will work on it.
During the past week I created also a login form and a little account toolbox for our WebUI as little draft of how this will be in future releases.
Last but not least I have a little problem with mockup softwares... I'm not much able to use them so I hope to soon upload some mockups.
So That's all for now folks! Thanks for your attention!

The WebUI

After midterm evaluation the developing of most difficult part is begun. The WebUI.

In a successful software the WebUI is the distinctive because is what we see most frequently and a good design is imperative.

To achieve this goal we use mojolicious that is a simple and even powerful web framework in Perl.

I have a little experience whit it but this is the right chance to gain more.

I started, during the past week, to setup the framework in our project but now is time to design something that can be easily understood from the user.

The UX must be simple for a standard user and even for an admin that will make some complex and tedious tasks (add a new GPIO, configure tags, etc.). My hope is to get the best result in the shortest possible time.

Now I'm talking very frequently on Skype with mudler to define what is the best design and what are the most dangerous mistakes trying to stay away from them.

One last thing, during the previous days I tested the SQLite Backend more deeper but the developing of the testsuite was postponed because of UX task. I plan to work on them as soon as possible.

That's all folks! Stay tuned and good work! 

First check point ok!

Very well I'm still here and I'm fine!
The past week was dedicated to the midterm evaluation, I had a little anxiety but I passed this step.
First of all let me thank my mentors Vytas and Mudler for their help and their positive evaluation of my work, my hope is to get to the end of this experience making some good code for all people who like this project.
However during the past days I continued my work on the project in both branches previously developed.
For the RPC branch I created a test suite for the dummy module.
But this caused the need of some other fixes in core modules, like the introduction of a new kind of signal (term) to stop safely mojolicious and the introduction of a yaml file to configure the RPC server.
Even on the SQLite branch we had some news. A script was added to fill the database with some testing data.
During a deep test of this code I encountered a problem in the Connector module implementation that was fixed introducing two accessors to the Node entity.
Then a little change introduced in the Config module let us the possibility to not specify some unrequired values.
So that's all for now, thanks again to my mentors. Stay tuned!