Page 1 sur 1

[xf86-video-intel] Sature le swap; pas la RAM ! (clôturé)

Publié : dim. 26 mai 2013, 05:58
par widapit
Salut !

Je me décide à poster : depuis que j'ai redemarré mon ordi ce soir, (et après un pacman -Syu vers 16h20) le swap s'emballe !!
et je n'ai aucune idée de pourquoi :shock: je n'ai rien changé dans les configs et quand je démarre, ça se passe bien pendant 10min un quart d'heure puis ça se déchaine et je passe rapidement (à peine 10 min. de plus) à + de 60% de SWAP utlisé et jusqu'à ce que je doives rebooter avant que tout freeze !
alors que la RAM se maintient un peu en-dessous de 30%, ce qui correspond à la conso habituelle (à part que cet ordi n'avait jamais swappé avant)... j'avoue que je ne sais pas trop par où chercher ... le /fstab n'a pas été touché (d'ailleurs il n'y a pas d'erreur au démarrage)
tout le système est sur SSD, j'ai donc dans le /etc/sysctl.conf :

Code : Tout sélectionner

vm.swappiness = 1
vm.vfs_cache_pressure = 50
comme conseillé d'après le wiki anglais .
30min. plus tard : :( Lorsque ça arrive, j'ai ce message d'erreur à l'extinction et ça bloque à ce moment, après tout les

Code : Tout sélectionner

[OK] Unmounted (.*)?
[OK]Stopped (.*)?
[OK] Closed Syslog Socket
puis il y a ces 2 lignes qui s'alternent en fait sur la même ligne . Les étoiles sont rouges et "se déplacent", simulant un chargement ...

Code : Tout sélectionner

[*** ] (1 of 2) A stopjob is running for /dev/disk/by-label/swap
[ ***] (2 of 2) A stopjob is running for /dev/disk/by-id/ata-TOSHIBA_(.*)?-part6
part6 correspond à /dev/sda6 qui correspond bien au swap .
ou alors, ça bloque sur quelque chose comme Reached Shutdown.target et quand je dis ça bloque c'est que dans un cas comme dans l'autre, il ne se passait plus rien. J'ai attendu 10min avant de forcer l'arrêt avec le bouton ... :cry:
en revanche, si je fais reboot ou poweroff avant que ça dégénère, il s'éteint ou reboot normalement ...

les mises à jour kernel datent de plus de 5 jours, donc reboot depuis, pas eu de soucis.. je ne pense pas que ce soit la cause...(d'ailleurs j'ai les mêmes résultats en FallBack et en LTS)
en fait, au vu des logs de pacman, je vois pas bien quel serait le responsable...

20-25min. plus tard : en cherchant un peu, j'ai cru commprendre que pour désactiver le swap c'était

Code : Tout sélectionner

swapoff -a
mais il répond qu'il ne peut pas allouer de mémoire ... :pleure:
j'ai aussi essayé de démarrer sans lancer FF et thunderbird qui sont gourmands, même sans rien lancer, juste un seul terminal (urxvt) ouvert, il fini par planter !!

:chinois: désolé pour la qualité de mon message mais j'essaie d'en mettre le plus possible avant de devoir rebooter ... pas facile de faire des recherches / tests par tranches d'un quart d'heure - vingt minutes ... c'est même assez pénible :vapeur:. Par moments, j'ai des latences de fou, sur de simples déplacements du curseur !! heureusement qu'on peut enregistrer des brouillons sur le forum !!

40min plus tard :mur:... rien par contre si je reste en tty... en fait je commence à soupçonner les pilotes intel; intel-dri intel-gpu-tools et xf86-video-intel ont été upgradés aujourd'hui même...

je vais essayer de downgrader d'abord ces 3 là ...

Edit: bon apparement c'est bien ça . Ça va faire bien plus d'une heure et pas le moindre % de swap à l'horizon :mrgreen: ... (avec un usage normal et toutes mes applis en même temps !!) donc pour le moment, je reste avec xf86-video-intel 2.21.6-1 et intel-dri 9.1.2-1.

Du coup, je modifie le titre et passe en contourné mais :
Attention donc à ceux qui s'apprêtent à faire cette fameuse mise à jour .
xf86-video-intel2.21.6-1 -> 2.21.7-1 , intel-dri 9.1.2-1 -> 9.1.3-1

m'en vais faire un tour sur le forum anglais voir si d'autres sont dans ce cas...
mais bon, entre ça et le régulateur "ondemand" qui a disparu de cpupower depuis intel_pstate
je commence à avoir peur avec ma machine "full intel" :transpi: :humour: ??

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (contour

Publié : dim. 26 mai 2013, 10:13
par chipster
Plop
Bizarre, j'ai fait la mise à jour et rien de spécial chez moi malgré 1h30 d'utilisation. Tu n'as pas de chance ^^'

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (contour

Publié : dim. 26 mai 2013, 13:47
par widapit
Salut,

oui, je pense qu'on est assez nombreux à utiliser ces paquets pourtant !! :wink:
c'est pour ça que je mettais en garde... mais apparemment je suis bien seul, j'ai rien trouvé de récent non plus sur le forum .org .
Pourtant, c'est forcément ça, j'ai rien fait d'autre et j'ai pas eu de soucis malgré un uptime de 4h15 ...
je suis perplexe .
au cas où :

Code : Tout sélectionner

$ hwinfo --gfxcard
08: PCI 02.0: 0300 VGA compatible controller (VGA)
  [Created at pci.319]
  Unique ID: _Znp.i5vYgxHIZnC
  SysFS ID: /devices/pci0000:00/0000:00:02.0
  SysFS BusID: 0000:00:02.0
  Hardware Class: graphics card
  Model: "Intel VGA compatible controller"
  Vendor: pci 0x8086 "Intel Corporation"
  Device: pci 0x0116 
  SubVendor: pci 0x1179 "Toshiba America Info Systems"
  SubDevice: pci 0x0005 
  Revision: 0x09
  Driver: "i915"
  Driver Modules: "drm"
  Memory Range: 0xc0000000-0xc03fffff (rw,non-prefetchable)
  Memory Range: 0xb0000000-0xbfffffff (ro,non-prefetchable)
  I/O Ports: 0x3000-0x303f (rw)
  IRQ: 40 (476164 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00008086d00000116sv00001179sd00000005bc03sc00i00"
  Driver Info #0:
    Driver Status: i915 is active
    Driver Activation Cmd: "modprobe i915"
  Config Status: cfg=new, avail=yes, need=no, active=unknown

Primary display adapter: #8

Code : Tout sélectionner

$ lsmod | grep -i intel
intel_powerclamp        8802  0 
kvm_intel             125437  0 
kvm                   390263  1 kvm_intel
crc32c_intel           14249  0 
ghash_clmulni_intel     4501  0 
cryptd                  8537  1 ghash_clmulni_intel
snd_hda_intel          35816  0 
snd_hda_codec         145704  3 snd_hda_codec_realtek,snd_hda_codec_hdmi,snd_hda_intel
snd_pcm                76860  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
snd_page_alloc          7330  2 snd_pcm,snd_hda_intel
snd                    58893  7 snd_hda_codec_realtek,snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_pcm,snd_hda_codec,snd_hda_intel
intel_agp              10936  1 i915
intel_gtt              12664  2 i915,intel_agp

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (contour

Publié : dim. 26 mai 2013, 18:53
par benjarobin
As tu essayé sans swap : Il suffit de commenter la ligne du fstab.
Est-ce que ce n'est pas un processus fous et dans ce cas le kernel décide pour je ne sais quel raison de le mettre en swap ?

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (contour

Publié : dim. 26 mai 2013, 21:15
par widapit
oui, j'ai essayé en commentant le fstab .
alors comme j'ai eu pas mal de reboots, avec de légères variantes, je suis plus trop sûr pour le coup :
- soit la charge CPU s'est emballée à son tour .
- soit il a frisé brusquement .
Et puis ce serait resté un contournement provisoire non ? :mrgreen:
Ce n'est pas un processus fous et le kernel décide pour je ne sais quel raison de le mettre en swap ?
je pense que oui, quelque chose comme ça .
parce-qu'en plus quand je disais 30% de RAM utlisé, c'était avec FireFox+autres, quand j'avais que mon terminal ouvert, il a mit plus de temps mais le swap s'est rempli aussi (env. 70% avant que je reboot proprement) alors que la RAM restait qu'à 4 ou 5% cette fois !

pour info: là, il est resté allumé depuis, soit uptime d'un peu plus de 12h maintenant et tout remarche nickel RAS.
mais c'est vrai qu'en y repensant, le swap se chargeait plus dès que je passais d'un bureau à l'autre, jonglais entre les terminaux ou les onglets... en fait dès que je sollicitait la CG .

À ton avis, j'attend une prochaine mise à jour voir si ça corrige le tir ou je dois faire un rapport de bug ?

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (contour

Publié : dim. 26 mai 2013, 21:47
par benjarobin
Je te conseil de chercher si le bug n'est pas déjà connu, et si ce n'est pas le cas de le rapporter

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (contour

Publié : lun. 27 mai 2013, 19:20
par widapit
OK,

Je m'en occupe .
Car effectivement, je reproduis le comportement en réinstallant xf86-video-intel 2.21.7-1 et reviens à la normale en downgradant . mais ça m'a aussi permis de récupérer des logs plus clairs parce-que pour la période de la premiere install du paquet jusqu'au premier downgrade :

Code : Tout sélectionner

# journalctl --since="2013-05-25 20:00:00" --until="2013-05-26 06:00:00" | wc -l
 14045 
:shock:
maintenant ,juste pour la session du nouveau test :
le pastebin (y' a quand même 891 lignes !)
mais en fait après la phase de boot y'a vraiment pas grand chose .

voici également les options noyau que j'utilise dans mon /boot/syslinux.syslinux.cfg, on sait jamais ... :

Code : Tout sélectionner

APPEND root=UUID=968ae4b7-f04b-4b19-b0ab-7ffb5187e7b2 ro acpi_osi=Linux acpi_backlight=vendor elevator=noop pcie_aspm=force i915.i915_enable_rc6=1 i915_enable_fbc=1 i915.lvds_downclock=1 i915.semaphores=1 pci=nocrs
EDIT : après vérif, la version 2.21.8-1 est dispo !!
J'installe, j'essaie, puis j'annonce le résultat :wink:

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (clôturé

Publié : lun. 27 mai 2013, 21:16
par widapit
voilà, il semblrait bien que la mise à jour salvatrice est été plus rapide que la confection du rapport !!

Code : Tout sélectionner

pacman -Qs xf86-video-intel
local/xf86-video-intel 2.21.8-1 (xorg-drivers xorg)
    X.org Intel i810/i830/i915/945G/G965+ video drivers
uptime à plus d'une heure et demi avec même un passage en veille ...
tout à l'air nickel !
Je passe donc en clôturé .

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (clôturé

Publié : lun. 27 mai 2013, 21:20
par Ypnose
La nouvelle version: 2.21.8
It turns out that there were a cow COW-related regressions that hit Wine applications and were causing a memory leak when using the Mozilla Firefox web-browser.
Donc oui, ça devrait effectivement résoudre ton soucis.
Source: http://www.phoronix.com/scan.php?page=n ... px=MTM3OTU

Re: [xf86-video-intel] Sature le swap; pas la RAM ! (clôturé

Publié : lun. 27 mai 2013, 21:37
par widapit
ok, donc ça a bien l'air d'être ça... merci pour la confirmation :wink: