.:: Home  |  Posts  |  GNU/Linux  |  Projects ::.

emanuele-f@galileo


Benvenuto nel mio spazio web, gentilmente hostato sul server galileo dell'università di Catania. In questo sito troverai materiale attinente al mondo dell'informatica, progetti, idee, articoli di varia natura.

About me

Mi chiamo Emanuele Faranda, sono un appassionato di informatica e programmazione e frequento attualmente il primo anno di Informatica all'Università di Catania.
Il mio tempo libero lo dedico ad acquisire nuove conoscenze su questo spettacolare mondo che ci permette, nel nostro piccolo, di diventare dei piccoli creatori, utilizzando fantasia e ingegno per creare un qualcosa che può essere ammirata dagli altri.
La mia filosofia di pensiero è vicina ai principi dell'opensource: le idee, così come i programmi, rappresentano per il mondo un patrimonio inestimabile; solo la loro libera circolazione permette alla società di crescere e progredire, di imparare dagli sbagli fatti da altri, e di costruire su solide fondamenta.

Questo sito, come molti altri, nasce dalla volontà di comunicare qualcosa, di dare in prima persona il mio contributo all'accrescimento delle informazioni presenti in rete che, si spera, possano essere d'aiuto ad altre persone.

Con tali premesse, risulta facile capire perchè gli articoli informatici presenti in questo sito sono orientati al mondo GNU/linux, simbolo della libertà e prodotto della collaborazione di persone di tutto il mondo. Il primo approccio può essere traumatico, è vero, ma una volta entrati in confidenza con il sistema ci si sente veramente padroni del proprio computer cosa che, ai giorni d'oggi, è considerato un lusso troppo grande dalle principali case sviluppatrici di hardware e software.

Come accedere ai contenuti

Nello sviluppo di questo sito, i miei obiettivi sono stati dal principio la velocità e semplicità di accesso alle informazioni, arricchendo il tutto con un aspetto piacevole.

I contenuti sono organizzati in post, a loro volta classificati tramite dei tag. Vi sono anche i progetti che sono una collezione di post relativi ad un argomento particolare.
I post possono essere visitati in ordine di scrittura, filtrati per tag, o tramite la lista dei post.

Spero che la tua permanenza sia piacevole e le informazioni trovate utili, per qualunque suggerimento, critica o semplici chiacchiere non esitare a contattami, il mio indirizzo email è black.silver@hotmail.it

Sito in lavorazione

Quando questa brutta scritta sparirà, il sito sarà pronto ad affrontare mesi o anni di avanzamento tecnologico prima di subire ingenti variazioni.
Fino a quel momento, ogni informazione presente in esso non deve essere considerata attendibile.

Changelog:
  • 18 Jul 2014 - Implemented ICV −Image Collection Viewer− to handle images thumblains
  • 31 May 2014 - Changed site appearance, removed right menu and postshell, fixed inproject links
  • 15 May 2014 - Improved post navigation controls
  • 15 May 2014 - Project mainpage index expansion
  • 22 Apr 2014 - Stats logging implemented
  • 01 Jan 2014 - Project mode implemented
  • 01 Jan 2014 - Removed header.php stuff
  • 31 Dec 2013 - Index inside the post
  • 29 Dec 2013 - Added homepage postview
  • 24 Dec 2013 - Removed page navigation & fixed post navigation
  • 24 Dec 2013 - Added tags filter
  • 24 Dec 2013 - Added page index
  • 24 Dec 2013 - Improved post controls behaviuor
  • 24 Dec 2013 - Added page navigation bar
  • 22 Dec 2013 - Code formatter used
  • 22 Dec 2013 - Style cleanup
  • 21 Dec 2013 - Upgraded page style
  • 15 Dec 2013 - Created background / header style
  • 15 Dec 2013 - Site push/pull script
  • 13 Dec 2013 - Added single view mode
  • 12 Dec 2013 - Added post navigation
  • 12 Dec 2013 - Added multipost parameters support
  • 11 Dec 2013 - Built php site structure
Todo:
  • Code cleanup
  • Feedback button
  • Search implement - combine list,tags

[12 posts] in emanuele-f@galileo

Multi-level Translation benefits

on 6 December 2014 − marked as #computer

Studying virtual memory implementations, you come across multilevel paged translation and derivates. After understanding how it works you ask yourself: why it is better than single paged models?.

# Test model ^

Let's assume a two levels model with LV1 and LV2 implemented as 10 bits and 10 bits in the address space and 4KB sized pages:

32bits address splitup:

    |31    LV1    22|21    LV2    12|11   OFFSET   0|

Let's try to inspect virtual addresses allocation with simple code:

#include <stdio.h>
int global;

int main()
{
    int stack;

    puts("Virtual addresses:");
    printf("\t Code is at '0x%08x'\n", main);
    printf("\tStack is at '0x%08x'\n", &stack-sizeof(stack));
    printf("\t Data is at '0x%08x'\n", &global-sizeof(global));
    return 0;
}

That gives me the following output:

Virtual addresses:
	 Code is at '0x0804842b'
	Stack is at '0xbfeff80c'
	 Data is at '0x08049780'

Running it multiple times only change the stack pointer, but '0xbf' is fixed. This happens because of stack randomization tecniques used to prevent stack overflow based attacks.

# The single page approach ^

In this approach, a single page is used to map the entire memory. Assuming a bound information is located somewhere and assuming page number is 20 bits long, in order to represent the highest virtual page used, which is 0xbfeff, the table should take at least 786175 * 4 ~ 3 MB total memory, requiring 3 * 2^20 / (4 * 2^10) = 768 physical pages to be hold!

        /------------\
      # | Page Table |
        |------------|
  00000 |  invalid   |
  00001 |  invalid   |
     .. |  invalid   |
  08048 |   valid    | --> Physical page base
  08049 |   valid    | --> Physical page base
    ... |  invalid   |
  bfeff |   valid    | --> Physical page base
       ---------------- (hopefully we stop here) ~ +3MB
    ... |  invalid   |
  fffff |  invalid   | +4MB
        \------------/

# The multilevel page approach ^

Let's split up the addresses in fields:

    |31    LV1    22|21    LV2    12|11   OFFSET   0|
    |---------------|---------------|---------------|
    |      020      |      048      |      42b      | 0x0804842b
    |      020      |      049      |      780      | 0x08049780
    |      2ff      |      2ff      |      80c      | 0xbfeff80c

Allocating a table of any level means allocating a memory page to hold its table entries. In the scheme above we need a single LV1 table, and 2 LV2 tables:

  • One for holding pointers for the two (048h)th and (049h)th positions
  • The other for holding the single (2ffh)th position

Trying to represent a memory snapshot of the situation and assuming no other page allocations are present, the memory should be organized in this way:

     /-----------\             /-----------\
   # | LV1 table |    ___\   # | LV2 table |
     |-----------|   /   /     |-----------|
 000 |  invalid  |   |     000 |  invalid  |
  .. |  invalid  |   |      .. |  invalid  |
 020 |   valid   | __/     048 |   valid   | --> Physical page base
  .. |  invalid  |         049 |   valid   | --> Physical page base
 2ff |   valid   | __       .. |  invalid  |
 300 |  invalid  |   \     3ff |  invalid  |
 ... |  invalid  |   |         \-----------/
 3ff |  invalid  |   |
     \-----------/   \____\    /-----------\
                          /  # | LV2 table |
                               |-----------|
                           000 |  invalid  |
                            .. |  invalid  |
                           2ff |   valid   | --> Physical page base
                            .. |  invalid  |
                           3ff |  invalid  |
                               |-----------|

Since each table takes up exactly one memory page, we only need to allocate 3 pages * 4 KB = 12 KB memory against the 768 pages needed in the single page approach!
This is a great advantage in systems where code and data is only located at high addresses whereas stack is allocated at low addresses; intermediate pages are only allocated as needed.
With this approach, essentially, only the LV1 table is allocated statically, the others are allocated only on need!
Another advantage is that each level can be protected/shared as a unit, allowing processes to share a big chunch of pages in one shot.

Fan speed with IT87 driver

on 25 May 2014 − marked as #gnu_linux

  • update 11 July 2014: added Fix hwmon order

Recently I bought a new CPU heatsink and fan, the Artic Cooling Alpine 64 Plus, to get rid of stock Athlon 64 X2 4400+ heatsing fan noise.
Surprisingly, after having installed the new heatsing, I can't notice any valuable noise variation.
At system startup, fan is quite silent, but after some work, it becomes very noisy, and doesn't speed down until shutdown.
After restart, BIOS reports that it is running at 4000 rpm, a very high value considering that Alpine fan should spin between 600-2000 rpm... there is something wrong out there!

# Software PWM control ^

Modern PC fans are able to be regulated by a pwm signal, which allows to dynamically vary fan speed. Q-FUN is a BIOS level control utility which regulates CPU fan speed acording to sensors reads...at least it should. In practise, Q-FUN doesn't work properly.
From now on, disable this function or it will interfer software control.
In Linux, a tool to control pwn fans is fancontrol. It's configuration can be automatically generated by pwmconfig utility. Unfortunately, when running pwmconfig on an Asus M2N-X Series motherboard with IT8712F sensor device, the following message appears:

There are no pwm-capable sensor modules installed
This could led one to think that this motherboard hasn't got a software interface to pwm control...it has, it is only a matter of driver :/

# "Bad" sensors drivers ^

After some investigation, I found that linux kernel uses atk0110 sensor driver for IT8712F, which seems not to support fan speed regulation. In the past it used IT87 sensor driver and, as reported by many posts, it supported fan speed regulation. Now IT87 is marked as a bad driver, since it's address range conflicts with the one ACPI uses and could really cause unpredictable hardware damages to hardware, be warned.
Nevertheless, no damage has been reported by now, so let's try to activate this module again.
Trying to manually start it87 kernel module with modprobe it87 you get:

modprobe: ERROR: could not insert 'it87': Device or resource busy
which simply means that address range is already taken from ACPI device.
In order to make it load, you must add the following argument to Linux kernel:
acpi_enforce_resources=lax
During boot, Linux should show something like this:
it87: Found IT8712F chip at 0x290, revision 8
[ 6.250477] it87: VID is disabled (pins used for GPIO)
[ 6.250524] ACPI Warning: SystemIO range 0x00000295-0x00000296 conflicts with OpRegion 0x00000290-0x000002af (\_SB_.PCI0.SBRG.SIOR.ECRE) (20131218/utaddress-258)
[ 6.250530] ACPI: This conflict may cause random problems and system instability
[ 6.250532] ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver
[ 7.675337] i2c i2c-0: nForce2 SMBus adapter at 0x600
[ 7.675372] i2c i2c-1: nForce2 SMBus adapter at 0x700
[ 7.686151] asus_atk0110: Resources not safely usable due to acpi_enforce_resources kernel parameter
which tells you that it87 driver is correctly enabled and is causing his dirty conflicts, but it's ok. Moreover, running systemctl status kmod (on a systemd based system) should return something like:
systemd-modules-load.service - Load Kernel Modules
Loaded: loaded (/lib/systemd/system/systemd-modules-load.service; static)
Active: active (exited) since Sun 2014-05-25 18:21:17 CEST; 1h 40min ago
Docs: man:systemd-modules-load.service(8)
man:modules-load.d(5)
Process: 210 ExecStart=/lib/systemd/systemd-modules-load (code=exited, status=0/SUCCESS)
which tells you that it87 module has been correctly loaded.

# PWM manual control ^

Having it87 kernel module up gives you the power to directly control pwm signals. Your current configuration could vary from mine, but general behaviour is the same.
Settings can be read/written to the following files:

  • /proc/self/root/sys/class/hwmon/hwmon0/device/pwm1_enable
    It contains 1 if pwm software control is enabled, 0 instead.
  • /proc/self/root/sys/class/hwmon/hwmon0/device/pwm1
    It contains the PWM value sent to the fan. It ranges from 0 to 255. High values increase fan speed, low values can even stop it!
  • /proc/self/root/sys/class/hwmon/hwmon0/device/pwm1_freq
    Contains the frequency, in Hz, of the pwm signal. As the standard imposes, it should be about 25 KHz.
I made pwmfantest, an utility to automatically set and show pwm1 values. Please note that IT87xx only updates its values each 1.5 seconds, so a 2 seconds wait between reads it's introduced.
First test gave me riddiculus wrong results! Fan speed seemed not to respond correctly to sent pulses...and noise indeed didn't stop.
I figured out that pwm1_freq was set to hold a value of 375KHz, which is a lot above the 25 KHz recommende value.
After writing 23437 value to pwm1_freq, I heard cpu fan spinning down.
A new test shows that fan control is now almost perfect: minimum rpm value I get is 823, which is only 200rpm above AC Alpine minimum reported value; maximum value is 4245 rpm against 2000rpm maximum Alpine stated value...I suspect that the measured values are doubled than the actual values.

# PWM automatic control ^

Anyway, now fan control works properly.
In order to automatically tweak values based on sensors reads you can use the pwmconfig utility, filling asked questions with custom pwm1 ranges which test utility pointed out.
It will generate /etc/fancontrol config file, which is read by fancontrol utility to adjust fan rotation. You may need to enable fancontrol autostart manually depending on your distro.
In my configuration I've chosen to set 40°C as starting temperature and 50°C as high temperature, whith pwm values from 11 to 255. It dinamically adapts to temperature changes and when cpu load is little, I can't even hear fan spinning!

Last thing to do is ensuring correct pwm1_freq is loaded ad startup. I've chosen to put this chunk of code into /etc/rc.local:

# Set custom PWM frequency
if [ -e /proc/self/root/sys/class/hwmon/hwmon0/device/pwm1_freq ] 
then
    echo 25437 > /proc/self/root/sys/class/hwmon/hwmon0/device/pwm1_freq
fi
For more information on pwm fan and sensors, visit www.tjansson.dk and archlinux wiki.

# Fix hwmon order ^

When kernel boots, kernel modules are loaded so that interface to underlying hardware is exposed to the operating system. One class of interfaces is monitor interface, which produces hwmon virtual devices. Modules are loaded at startup but module order is not ensured to be kept across reboots.
Since fancontrol uses hwmon classes to identify devices, it could happen that monitor device number is not preserved, leading to fancontrol fail. A trick to fix hwmon order, imposing specific module load order, is the following:

  1. Run fancontrol to identify monitor modules
  2. Create a new blacklist file in /etc/modprobe.d/, let's say sensors.conf
  3. For each module, add a line to sensors.conf like 'blacklist module_name'
  4. For each module, add a line with module name to /etc/modules
Now modules will be loaded respecting /etc/modules specified order, which should create hwmon devices acordingly.
Obviously, this is only a workaround, fancontrol should use absoule module names like those listed in /sys/devices/platform instead of relying on hwmon identifier.

Page: 1 of 6