[KERNEL] Freeze avec la lib pata

Ubitux · Message par **Ubitux** » mar. 30 janv. 2007, 18:38

Oups je n'ai pas été très malin, désolé...

Mélodie : pour l'interface graphique je ne pense pas que ça change grand chose, cpa la peine de crier

j'explique encore une fois pour mon problème de freeze : ce ne sont pas vraiment des freezes : les applications se figent une par une dès que je les utilises (surement au moment d'un accès au disque).
Par exemple, imaginons que je sois en plein "freeze", je peux dans une console commencer à taper quelque chose, mais si je presse "tab" par exemple, la console fige, et ça me fait la même chose pour les autres apply. Autre exemple, toujours pendant un freeze, si je tape "dmesg", la console va freezer, et une fois les 30 secondes écoulées, le retour de la commande s'affichera... donc que je sois dans un tty ou une console ça ne changera pas grand chose (j'ai d'ailleurs fait l'essai). Les moniteurs comme conky ne se figent par exemple, et l'horloge continue de tourner. La musique se coupe, et dès que les 30 secondes sont écoulées, toute la musique qui aurait du sortir sort d'un coup :p

Autre chose, pour dbus-monitor, quelle synthaxe je dois utiliser ? Il me demande de faire appel au man de dbus-launch et dbus-monitor, sauf que je ne sais pas exactement ce que je cherche à faire.

mimas · Message par **mimas** » mar. 30 janv. 2007, 18:53

ubitux a écrit :Autre chose, pour dbus-monitor, quelle synthaxe je dois utiliser ? Il me demande de faire appel au man de dbus-launch et dbus-monitor, sauf que je ne sais pas exactement ce que je cherche à faire.

heu... dbus-monitor. Tu peux ajouter --system pour monitorer le bus système au lieu de celui de la session.

Je ne comprends pas pourquoi il te demande de faire appel à dbus-launch, sauf si dbus n'est pas lancé dans ce cas.

Tu as déjà fait des fouilles archéologiques dans le sous-sol ? Tu as peut-être un cimetière indien en dessous de chez toi.

Ubitux · Message par **Ubitux** » mar. 30 janv. 2007, 18:59

Oui ok avec la session ça merdait... bon voilà j'ai lancé ceci dans le deuxième tty :
$ dbus-monitor --system > dbus

En root c'est pas mieux ?

Bon voilà dès que j'ai un nouveau freeze je vous fait un rapport...

C'est quoi cette métaphore ? Non je n'ai pas installé Apache, pourquoi ?

mélodie · Message par **mélodie** » mar. 30 janv. 2007, 20:31

Ubitux a écrit :C'est quoi cette métaphore ?

Quand la machine est hantée, on se voit recommander de mettre des gousses d'ail accrochées à l'écran :/

Cactus · Message par **Cactus** » mar. 30 janv. 2007, 23:05

[TROLL]

Ah, c'est donc pour ça qu'on dit que "Windows ça pue !" ?
[/TROLL]

ok, je suis déjà dehors... très loin... trop loin, n'essayez pas de me rattraper... vous savez, ça n'en vaut pas vraiment la peine, hein ?

Ubitux · Message par **Ubitux** » mar. 30 janv. 2007, 23:14

mélodie a écrit :
Ubitux a écrit :C'est quoi cette métaphore ?
Quand la machine est hantée, on se voit recommander de mettre des gousses d'ail accrochées à l'écran :/

J'ai pas compris la blague...

mélodie · Message par **mélodie** » mar. 30 janv. 2007, 23:40

Ubitux a écrit :
mélodie a écrit :
Ubitux a écrit :C'est quoi cette métaphore ?
Quand la machine est hantée, on se voit recommander de mettre des gousses d'ail accrochées à l'écran :/
J'ai pas compris la blague...

L'ail c'est contre les vents pires. ;o)

Cactus · Message par **Cactus** » mer. 31 janv. 2007, 00:48

mélodie a écrit :L'ail c'est contre les vents pires. ;o)

Joli !

Ubitux · Message par **Ubitux** » mer. 31 janv. 2007, 13:53

Hum... j'ai pas tout suivi là...
Peu importe, bon j'ai eu un freeze, mais le dbus qui tournait en fond n'a rien détecté de spécial, j'ai juste un output rempli de ceci :

signal sender=:1.0 -> dest=(null destination) path=/org/freedesktop/Hal/devices/acpi_BAT1; interface=org.freedesktop.Hal.Device; member=PropertyModified
int32 1
array [
struct {
string "battery.voltage.current"
boolean false
boolean false
}
]

Toujours ça, sauf peut-etre ceci qui est apparu 2 ou 3x :

signal sender=:1.0 -> dest=(null destination) path=/org/freedesktop/Hal/devices/acpi_LID0; interface=org.freedesktop.Hal.Device; member=PropertyModified
int32 1
array [
struct {
string "button.state.value"
boolean false
boolean false
}
]

'fin bref, rien qui concerne mon problème je pense...

Ubitux · Message par **Ubitux** » mer. 07 févr. 2007, 00:01

J'ai toujours les même freezes avec le kernel 2.6.20...

Voici les nouveaux messages d'erreurs :

ata1.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata1.01: cmd a0/01:00:00:00:00/00:00:00:00:00/b0 tag 0 cdb 0x25 data 8 in
res 40/00:03:00:00:00/00:00:00:00:00/b0 Emask 0x4 (timeout)
ata1: port is slow to respond, please be patient (Status 0xd0)
ata1: port failed to respond (30 secs, Status 0xd0)
ata1: soft resetting port
ata1.00: configured for UDMA/100
ata1.01: configured for UDMA/33
ata1: EH complete
SCSI device sda: 219538272 512-byte hdwr sectors (112404 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
SCSI device sda: 219538272 512-byte hdwr sectors (112404 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA

Je vais craquer... j'attendais ce kernel comme le messie et voilà que ça freeze toujours...

Avec le noapic j'ai ce message aussi dans /var/log/messages :

Enabling APIC mode: Flat. Using 1 I/O APICs

On sait jamais ça peut aider.

Demain, je teste en killant X et tout ce qui se rapporte à Nvidia pour voir si ça ne viens pas des drivers proprio, ça n'a peut-être rien à voir, mais bon, au point où j'en suis...

mélodie · Message par **mélodie** » mer. 07 févr. 2007, 08:27

Ubitux a écrit : Demain, je teste en killant X et tout ce qui se rapporte à Nvidia pour voir si ça ne viens pas des drivers proprio, ça n'a peut-être rien à voir, mais bon, au point où j'en suis...

Si tu ne lance pas d'interface graphique tu as peu de chance que les applications graphiques se figent.

Sur ma machine aussi il y a des freeze de temps en temps. J'ai remarqué que ça se produit quand j'ai Firefox ouvert avec plusieurs onglets, en même temps que Gimp, Konqueror, Acroread, Sylpheed, OpenOffice et Amarok, plus quelques instances de Terminal et les processus habituels en tâche de fond. Il faut dire qu'il y a 1 Go de RAM sur cette machine. Avec le laptop qui compte 256+128, je n'ose pas ouvrir autant d'applications "si légères" en même temps...

Tu pourrais faire une recherche sur le web avec ces messages d'erreur en mots-clés, il y a pas mal d'entrées concernant le même problème:

ata1: port is slow to respond, please be patient (Status 0xd0)

ata1: port failed to respond (30 secs, Status 0xd0)

Il y en a un qui parle du driver Nvidia qu'il a upgradé:

I upgraded to the beta nvidia-drivers 1.0.9742 which are masked [~x86][M] in gentoo.
System seems to be running better now although I did still get an
system error message:(...)

Ci-dessous un post récent:

> NVRM: loading NVIDIA Linux x86_64 Kernel Module 1.0-9631 Thu Nov 9 17:35:27 PST 2006 [...]

Notice how the problems started exactly at the point the "NVRM" NVIDIA module (whatever it is) was loaded ...

Si tu penses que le driver de ta carte graphique peut être en cause, tu devrais comme lui voir un message relatif au driver dans les sorties...

Ubitux · Message par **Ubitux** » mer. 07 févr. 2007, 12:54

Si tu ne lance pas d'interface graphique tu as peu de chance que les applications graphiques se figent.

Le freeze ne concerne pas seulement les applications ; les tty sont figés aussi dès que je lance une commande (durant les 30 sec de freeze)...
un dmesg m'indiquera d'ailleurs si j'en ai eu ou pas...

Mais bon... comme je n'ai pas réussi à killer complètement X (killall X, kill -9 [le pid de X], rmmod nvidia, killall slim, etc.)
Donc je n'ai pas pu tester.

Sur ma machine aussi il y a des freeze de temps en temps. J'ai remarqué que ça se produit quand j'ai Firefox ouvert avec plusieurs onglets, en même temps que Gimp, Konqueror, Acroread, Sylpheed, OpenOffice et Amarok, plus quelques instances de Terminal et les processus habituels en tâche de fond. Il faut dire qu'il y a 1 Go de RAM sur cette machine. Avec le laptop qui compte 256+128, je n'ose pas ouvrir autant d'applications "si légères" en même temps...

J'ai 1 Go de ram DDR2 et un bon CPU, et les freezes peuvent survenir à n'importe quel moment, quelque soit la charge du CPU, de la ram, etc... ce n'est pas un problème de performance, ça j'en suis sur.

Tu pourrais faire une recherche sur le web avec ces messages d'erreur en mots-clés

Oui c'est d'ailleurs ce que j'ai fait, et je ne suis pas le seul, mais apparemment les conditions ne sont pas les mêmes, et les solutions... bah je n'en ai pas trouvé.

Il y en a un qui parle du driver Nvidia qu'il a upgradé

Effectivement, j'ai vu ça oui. C'est d'ailleurs pourquoi je voulais tester en killant X. J'ai, depuis que j'ai upgradé mon kernel et le driver de ma carte graphique ceci (dmesg) :

PCI: Setting latency timer of device 0000:01:00.0 to 64
NVRM: loading NVIDIA UNIX x86 Kernel Module 1.0-9746 Fri Dec 15 09:54:45 PST 2006
**WARNING** I2C adapter driver [NVIDIA i2c adapter 0 at 1:00.0] forgot to specify physical device; fix it!
**WARNING** I2C adapter driver [NVIDIA i2c adapter 1 at 1:00.0] forgot to specify physical device; fix it!
**WARNING** I2C adapter driver [NVIDIA i2c adapter 2 at 1:00.0] forgot to specify physical device; fix it!

Je suis allé voir sur les forums Nvidia, mais il semblerait que ce soit un message sans importance :s
Et j'avais mes freezes avant même d'installer cette dernière version (dont les messages lui sont spécifiques ; j'avais jamais vu ça auparavant)

Faudrait que je teste avec le module "nv" à la place de "nvidia" en fait... en espérant que ça change quelque chose.

Message par **warnaud** » mer. 07 févr. 2007, 14:28

Ubitux a écrit : Mais bon... comme je n'ai pas réussi à killer complètement X (killall X, kill -9 [le pid de X], rmmod nvidia, killall slim, etc.)
Donc je n'ai pas pu tester.

Pour virer completement X :
tu te logues sur un tty en tant que root puis tu tapes :

Code : Tout sélectionner

telinit 3

ça devrait largement le calmer

Ensuite tu peux arrêter slim :

Code : Tout sélectionner

/etc/rc.d/slim stop

ensuite, pour tester ton X, tu fais les changements dans /etc/X11/xorg.conf, puis tu reviens en runlevel 5 via :

Code : Tout sélectionner

telinit 5

Ubitux · Message par **Ubitux** » mer. 07 févr. 2007, 21:15

Il se pourrait que ça vienne des drivers nvidia... j'ai booté sans le noapic (pour augmenter la fréquence des freezes), et juste avant de killer X et co, j'ai évidemment immédiatement eut des freezes (dans les tty aussi, je rappelle...). Après avoir viré X, nvidia, etc, je n'ai plus eut de freezes du tout.

Comment ça se fait que les drivers proprio me fassent ça ?

En quoi ça touche à mon HD ?

Je vais relancer le topic sur le forum nvidia, en espérant une réponse, d'ici là, si vous pouviez m'éclairer...

Merci.

Edit : bon voilà je viens de poster.
Voici l'adresse du topic : http://forums.nvidia.com/index.php?showtopic=23255

Message par **warnaud** » jeu. 08 févr. 2007, 03:07

Je pense pas que ça soit les drivers nvidia, car comme tu l'as dit

En quoi ça touche à mon HD ?

Bon, perso j'ai eu des trucs dans le même style sous Sourcemage après avoir un peu exagéré dans la config de mon bios sur les paramêtres des mes disques durs => mets au maximum en "auto" laisses tomber les transfert de données 32bits ...
Ensuite, tes disques ne sont pas en SATA ? Si ils n'y sont pas tu peux tester 2 choses :
- booter sur l'image fallback

Code : Tout sélectionner

title=Arch linux
kernel /boot/vmlinuz26 root=/dev/hda5 ro 
initrd /boot/kernel26-fallback.img

Si ça passe, regardes le fichier /etc/mkinitcpio.d/kernel26-fallback.conf
Et compares le avec le tiens ( /etc/mkinitcpio.conf )
Puis regénères ton image initcpio :

Code : Tout sélectionner

mkinitcpio -g /boot/kernel26.img

Si ça tourne toujours pas :
Rajoute MODULES="ide_generic" dans /etc/mkinitcpio.conf ou enlève 'pata' et remplace le par 'ide' dans les HOOKS
Regénère ton image mkinitcpio
ATTENTION !!! : si tu remets 'ide' dans les HOOKS il faut que dans ton fstab tu reviennes à "l'ancienne notation" /dev/hdX ...

Voilou ... j'espère que ça tournera.
Sinon commence un exorcisme de ton PC + bureau + la maison voire la ville complète.

mélodie · Message par **mélodie** » jeu. 08 févr. 2007, 08:36

warnaud a écrit :Sinon commence un exorcisme de ton PC + bureau + la maison voire la ville complète.

Humm...
++Linux in exorcism++ Google 24 000 pages en français. Encore pire, le 14 Décembre 2005 un miracle ! il entendait des voix dans ses enceintes.
Mon ordi parle !

marc[i1] · Message par **marc[i1]** » jeu. 08 févr. 2007, 08:37

warnaud a écrit :Voilou ... j'espère que ça tournera.
Sinon commence un exorcisme de ton PC + bureau + la maison voire la ville complète.

Sinon tu peux aussi allez chez Mc Do et égorger des nuggets !

:inutile:

Ubitux · Message par **Ubitux** » jeu. 08 févr. 2007, 12:47

warnaud a écrit :Je pense pas que ça soit les drivers nvidia, car comme tu l'as dit
En quoi ça touche à mon HD ?
Bon, perso j'ai eu des trucs dans le même style sous Sourcemage après avoir un peu exagéré dans la config de mon bios sur les paramêtres des mes disques durs => mets au maximum en "auto" laisses tomber les transfert de données 32bits ...
Ensuite, tes disques ne sont pas en SATA ? Si ils n'y sont pas tu peux tester 2 choses :
- booter sur l'image fallback
Code : Tout sélectionner
title=Arch linux
kernel /boot/vmlinuz26 root=/dev/hda5 ro 
initrd /boot/kernel26-fallback.img
Si ça passe, regardes le fichier /etc/mkinitcpio.d/kernel26-fallback.conf
Et compares le avec le tiens ( /etc/mkinitcpio.conf )
Puis regénères ton image initcpio :
Code : Tout sélectionner
mkinitcpio -g /boot/kernel26.img
Si ça tourne toujours pas :
Rajoute MODULES="ide_generic" dans /etc/mkinitcpio.conf ou enlève 'pata' et remplace le par 'ide' dans les HOOKS
Regénère ton image mkinitcpio
ATTENTION !!! : si tu remets 'ide' dans les HOOKS il faut que dans ton fstab tu reviennes à "l'ancienne notation" /dev/hdX ...

Voilou ... j'espère que ça tournera.
Sinon commence un exorcisme de ton PC + bureau + la maison voire la ville complète.

Transfert de données 32 bits ?
Pour le SATA je ne sais toujours pas ^^
Le boot sur l'image fallback, je peux le faire à partir de grub non ? et je laisse sda5, et pas hda5, non ?
Pour regénérer ? Quel est le lien avec la comparaison des fichiers ?

Si ça ne boot plus du à la modif de mon fstab, j'aurais un prompt root pour effectuer la modif ?

Merci Warnaud de ton aide, j'essaye ça ce soir

(LoL pour l'exorcisme :p)

Message par **warnaud** » jeu. 08 févr. 2007, 14:50

Ubitux a écrit : Transfert de données 32 bits ?

Il va falloir que tu fasses un tour dans ton BIOS ...
Les disques durs permettent un transfert de données 32bits, c'est une options normalement non activée (et que tu dois virer si elle y est, au moins pour le test)

Ubitux a écrit : Pour le SATA je ne sais toujours pas ^^

C'est pas bien !! Pareil c'est marqué dans ton BIOS

Ubitux a écrit : Le boot sur l'image fallback, je peux le faire à partir de grub non ? et je laisse sda5, et pas hda5, non ?

NON rajoute une entrée dans ton grub ça sert toujours une image fallback
Oui, tant que t'as pas regénéré l'image pour utiliser l'ancienne nomenclature laisse en /dev/sda5

Ubitux a écrit : Pour regénérer ? Quel est le lien avec la comparaison des fichiers ?

Ben c'est que ça utilise pas le même module .. et donc faut bien trouver d'où ça vient ... donc on désactive les modules EXPERIMENTAUX que des malades mentaux ont activés de base ...

Ubitux a écrit : Si ça ne boot plus du à la modif de mon fstab, j'aurais un prompt root pour effectuer la modif ?

Non !! D'où l'utilitée d'avoir une image fallback si ça déconne.
=> dans ton /boot/grub/menu.lst
Tu modifieras ton entrée avec l'image normale avec /dev/hda5
Après au prompt grub tu pourras modifier /dev/sda5 en hda5 sur l'entrée fallback

Ubitux a écrit : Merci Warnaud de ton aide, j'essaye ça ce soir

Alors je récapitule :
1. passer de nvidia à nv
si ça freeze encore
2. booter sur l'image fallback
- si ça freeze encore : tenter de passer en version full ide
- si ça freeze plus : comparrer les 2 images (comme indiqué plus haut) et se refaire une image "normale" avec les bons paramêtres

Ubitux a écrit : (LoL pour l'exorcisme :p)

Ubitux · Message par **Ubitux** » jeu. 08 févr. 2007, 17:58

warnaud a écrit :
Ubitux a écrit :Transfert de données 32 bits ?
Il va falloir que tu fasses un tour dans ton BIOS ...
Les disques durs permettent un transfert de données 32bits, c'est une options normalement non activée (et que tu dois virer si elle y est, au moins pour le test)

Je suis allé voir dans le BIOS et je n'ai rien de vu de tel...

warnaud a écrit :
Ubitux a écrit :Pour le SATA je ne sais toujours pas ^^
C'est pas bien !! Pareil c'est marqué dans ton BIOS

Même réponse... rien dans le bios à ce sujet. J'ai juste : "Disque Dur : 112 Go" (normalement c'est 120...)
Au selecteur d'ordre de boot je peux voir le modèle, mais je n'ai aucune info sur le type de bus.
D'ailleurs tu peux voir un peu l'étendue du problème ici : http://forums.archlinux.fr/post3090.html#3090

warnaud a écrit :
Ubitux a écrit : Le boot sur l'image fallback, je peux le faire à partir de grub non ? et je laisse sda5, et pas hda5, non ?
NON rajoute une entrée dans ton grub ça sert toujours une image fallback
Oui, tant que t'as pas regénéré l'image pour utiliser l'ancienne nomenclature laisse en /dev/sda5

J'ai déjà cette image fallback que je peux sélectionner au boot :

# (1) Arch Linux
title Arch Linux Fallback
root (hd0,0)
kernel /vmlinuz26 root=/dev/sda3 ro
initrd /kernel26-fallback.img

Elle devrait aller non ?

En attendant je vais tester avec le module "nv".

Merci encore pour ton aide précieuse