# [Sandy Bridge] Toujours des problèmes ?

## Damiatux

Bonjour,

Ayant envie de changer de configuration, je penche sur le fait de savoir si avec les Sandy Bridge il y a encore des problèmes avec le noyau. J'ai lu quelques sujets en Anglais, mais n'étant pas très fort sur ce point, je demande confirmation.

Damiatux

----------

## Zoboulo

Oui, toujours des problèmes ! Chez moi le suspend-to-ram ne fonctionne pas ... sur un pc fixe ! Attends encore quelques mois à mon avis ! Et vu qu'Ivy bridge est prévu pour dans moins d'un an ...

----------

## Fenril

Je up ce topic car je me suis fait une config récemment à base de Sandy Bridge. Avec l'IGP du processeur, je suis limité à du 1024x768@60Hz, ce qui n'est vraiment pas top. Heureusement je dispose d'un IGP sur la carte mère qui est un bête Intel classique retrouvé dans de nombreuses cartes-mères. Ce n'est pas un gros souci puisque j'envisage rapidement de m'acheter une vraie carte graphique. Ce pendant je suis curieux de savoir si quelqu'un a réussi à faire tourner une plateforme Sandy Bridge parfaitement.

----------

## guilc

La question est : fais-tu tourner du arch ou du ~arch ?

A priori les version ~arch devraient suffire pour faire tourner correctement du sandy bridge (ceci dit, je n'ai pas testé, c'est juste ce que me disent mes lectures).

----------

## Enlight

Il me semble avoir lu récemment que linux 3.0 supporte correctement le sandy bridge.

----------

## d2_racing

Moi aussi j'ai vu passé ça. Je pense que j'ai lu ça sur phoronix.

----------

## Fenril

Testé avec les gentoo-sources 3.0.4. Je suis toujours limité en 1024x768. Tant pis.

----------

## d2_racing

Même GCC n'aime pas les Sandy : https://bugs.gentoo.org/show_bug.cgi?id=360927

Il est plus sage d'utiliser GCC 4.6 avec ce genre de processeur.

----------

## Fenril

Bon,j'ai réussi à avoir autre chose que du 1024x768 avec les Modeline, heureusement pour me yeux. C'est franchement dommage que ça ne le fasse pas automatiquement.

----------

## El_Goretto

 *d2_racing wrote:*   

> Même GCC n'aime pas les Sandy : https://bugs.gentoo.org/show_bug.cgi?id=360927
> 
> Il est plus sage d'utiliser GCC 4.6 avec ce genre de processeur.

 

AAaaaah, je me suis fait plaisir en me payant ce bug, je suis passé à gcc 4.6.1 sur mon desktop.

Hahaaaaa, vite, emerge -e world, qu'on vérifie si un truc pète et.... ben non, juste thunderbird-3.1.12, en passant à la thunderbird 6.0 nickel.

Raaah, j'ai rien cassé! Bouuuuuh!   :Rolling Eyes: 

----------

## d2_racing

AS-tu pris native ou corei7 ?

----------

## El_Goretto

Ah, native, pourquoi? Aurais-je involontairement esquivé des difficultés? Diantre!   :Surprised: 

----------

## El_Goretto

 *d2_racing wrote:*   

> AS-tu pris native ou corei7 ?

 

Bon, j'ai appliqué la "méthode guilc (c)" et... je n'ai pas compris le résultat, qu'on pourrait considérer comme contraire à ce qui est attendu (ou bien j'ai encore raté quelque chose   :Confused:  ):

```
# gcc -Q -march=native --help=target > native

# gcc -Q -march=corei7-avx --help=target > corei7

# colordiff native corei7

13c13

<   -maes                                       [enabled]

---

>   -maes                                       [disabled]

22c22

<   -mavx                                       [enabled]

---

>   -mavx                                       [disabled]

30c30

<   -mcx16                                      [enabled]

---

>   -mcx16                                      [disabled]

58c58

<   -mno-sse4                                   [disabled]

---

>   -mno-sse4                                   [enabled]

61,62c61,62

<   -mpclmul                                    [enabled]

<   -mpopcnt                                    [enabled]

---

>   -mpclmul                                    [disabled]

>   -mpopcnt                                    [disabled]

71c71

<   -msahf                                      [enabled]

---

>   -msahf                                      [disabled]

73,74c73,74

<   -msse                                       [enabled]

<   -msse2                                      [enabled]

---

>   -msse                                       [disabled]

>   -msse2                                      [disabled]

76,79c76,79

<   -msse3                                      [enabled]

<   -msse4                                      [enabled]

<   -msse4.1                                    [enabled]

<   -msse4.2                                    [enabled]

---

>   -msse3                                      [disabled]

>   -msse4                                      [disabled]

>   -msse4.1                                    [disabled]

>   -msse4.2                                    [disabled]

83c83

<   -mssse3                                     [enabled]

---

>   -mssse3                                     [disabled]

90c90

<   -mtune=                                     corei7-avx

---

>   -mtune=

```

"Et là, c'est le drame"

Comment, par exemple, l'AVX peut-il est non activé sur un profile "corei7-avx"

----------

## guilc

Original... A croire que le profil native active plus d'options pour ton CPU... Le profil corei7-avx n'aurait pas fini de sécher ?

Y a même un truc qui me semble étrange, march=native positionnerait un mtune=corei7-avx ??? Tu es sûr de ne pas avoir inversé les diff ?   :Confused: 

----------

## El_Goretto

 *guilc wrote:*   

> Tu es sûr de ne pas avoir inversé les diff ?  

 

Sûr de chez sûr chef, j'ai même utiliser des mots clés bidons à la place d'un profil valable, ça renvoie toujours le même résultat.   :Shocked: 

Précisément "gcc -Q -march=truc --help=target" renvoit la même chose que "gcc -Q -march=corei7-avx --help=target", pareil avec core2, machin, pouet...

Il y a pas gamelle, genre je spécifie mal quelque chose?

--

edit:

je viens de faire le même test sur un atom avec un gcc 4.4, même symptôme, dès que ce n'est pas native, le résultat est identique à un profile incorrect:

```
elgo@twat ~/tmp $  colordiff native core2

23c23

<   -mcx16                                      [enabled]

---

>   -mcx16                                      [disabled]

56c56

<   -msahf                                      [enabled]

---

>   -msahf                                      [disabled]

74c74

<   -mtune=                                     core2

---

>   -mtune=

elgo@twat ~/tmp $ colordiff truc core2

17c17

<   -march=                                     truc

---

>   -march=                                     core2

```

----------

## netfab

Petit up, je viens de tomber sur le problème, et après quelques recherches, bug gcc, apparemment toujours d'actualité (gcc-4.5.3-r1) :

gcc -Q --help=target does not list extensions selected by -march=

----------

