Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Linux Autres OS Linux Problèmes lors de l'arrêt d'un portable AMD 64 sous Mandrake 10.2 x86_64

Problèmes lors de l'arrêt d'un portable AMD 64 sous Mandrake 10.2 x86_64

25 réponses
Avatar
Olivier V
Bonjour,

Lors de l'arrêt de mon portable (décrit dans le titre),
j'ai deux erreurs. :

- L'une contient un tas de chiffres et de lettres
et notamment les mots "cpufreq" et "acpi"
- L'autre est juste après celle d'avant et est la suivante :
Déchargement des modules cpufreq :
/etc/rc0.d/K35cpufreq: line 199: 11864 Killed rmmod $MODULE 2>/dev/null
Echec

Par ailleurs, après le
"shutdown: hda",
la machine ne s'éteint (ni ne reboote) toute seule,
je suis obligé d'appuyer plusieurs secondes sur le bouton marche/arrêt.
Comment remédier à cela ?

Merci beaucoup.

Olivier V

P.S. : Quel fichier contient l'intégralité des messages de sortie ?
car actuellement, je recopie à la main ...
Signaler un problème avec ce contenu

5 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
1 2 3
Avatar
Nicolas S.
En fait le problème ne vient aparamment pas du SMP.


Je pense que l'usage du SMP pour ce type de processeur ne convient tout
de même pas. Je n'ai malheureusement pas de tel matériel sous la main et
ne peut donc pas le confirmer.

En effet, je viens de m'apercevoir que la Mandrake 64 était livrée avec un
deuxième noyau "prêt à l'emploi" compilé sans le support SMP :


Bien. Il faut savoir que l'implémentation du 64 bits est relativement
récent. Il se peut donc qu'il y ait encore des bugs.
On peut évidemment essayer de chercher plus loin l'origine du problème;
ceci dit, cela demandera beaucoup d'investissement personnel. Un kernel
Oops n'est jamais bon...
Je vous conseille d'utiliser la version 32 bits stable en attendant.
Si vous voulez aller plus loin, fournissez plus d'info:
# dmesg |grep -i powernow
# dmesg |grep -i cpu
# cat /proc/acpi/processor/CPU0/power
# cat /proc/acpi/processor/CPU0/info
# cat /proc/cpuinfo

J'essaierais alors de voir s'il s'agit d'un bug connu.


ftp://ftp.free.fr/pub/Distributions_Linux/Mandrakelinux/official/2005/x86_64/media/main/kernel-2.6.11.6mdk-1-1mdk.x86_64.rpm
ftp://ftp.free.fr/pub/Distributions_Linux/Mandrakelinux/official/2005/x86_64/media/main/kernel-smp-2.6.11.6mdk-1-1mdk.x86_64.rpm

J'ai installé ce noyau sans SMP, booté dessus, et j'ai toujours la même
erreur :

May 6 20:16:53 localhost cpufreq: Déchargement des modules cpufreq :
May 6 20:16:53 localhost kernel: Unable to handle kernel NULL pointer
dereference at 0000000000000030 RIP:
May 6 20:16:53 localhost kernel:
<ffffffff8813ef96>{:processor:acpi_processor_unregister_performance+43}
May 6 20:16:53 localhost kernel: PGD 3ad1f067 PUD 3cb15067 PMD 0
May 6 20:16:53 localhost kernel: Oops: 0000 [1]
May 6 20:16:53 localhost kernel: CPU 0
May 6 20:16:53 localhost kernel: Modules linked in: cpufreq_powersave
powernow-k8 raw md5 ipv6 rfcomm l2cap bluetooth snd-seq-dummy snd-seq-oss
snd-seq-midi-event snd-seq snd-seq-device snd-pcm-oss snd-mixer-oss
snd-intel8x0 snd-ac97-codec snd-pcm snd-timer snd-page-alloc snd soundcore
af_packet pcmcia yenta_socket rsrc_nonstatic pcmcia_core video thermal
tc1100-wmi processor fan container button battery ac eth1394 sis900 ide-cd
ohci1394 ieee1394 loop nls_cp850 vfat fat nls_iso8859-15 ntfs nvram evdev
dm-mod ehci-hcd ohci-hcd usbcore ext3 jbd
May 6 20:16:53 localhost kernel: Pid: 8553, comm: rmmod Not tainted
2.6.11-6mdk
May 6 20:16:53 localhost kernel: RIP: 0010:[_end+130469782/2131943424]
<ffffffff8813ef96>{:processor:acpi_processor_unregister_performance+43}
May 6 20:16:53 localhost kernel: RIP: 0010:[<ffffffff8813ef96>]
<ffffffff8813ef96>{:processor:acpi_processor_unregister_performance+43}
May 6 20:16:53 localhost kernel: RSP: 0018:ffff81003b799d78 EFLAGS:
00010286
May 6 20:16:53 localhost kernel: RAX: 0000000000000000 RBX:
ffff81003dfae000 RCX: 0000000000000030
May 6 20:16:53 localhost kernel: RDX: 0000000000000001 RSI:
0000000000000000 RDI: ffffffff88141980
May 6 20:16:53 localhost kernel: RBP: ffffffff88141980 R08:
0000000000000000 R09: 00000000000000aa
May 6 20:16:53 localhost cpufreq: /etc/rc6.d/K35cpufreq: line 199: 8553
Killed rmmod $MODULE 2>/dev/null
May 6 20:16:53 localhost cpufreq: failed
May 6 20:16:53 localhost cpufreq: ^[[65G[^[[1;31m
May 6 20:16:53 localhost kernel: R10: 0000000000000000 R11:
ffffffff8022a510 R12: ffff81003c45f8c8
May 6 20:16:53 localhost kernel: R13: ffffffff803d7780 R14:
0000000000000880 R15: 00007ffffffffc18
May 6 20:16:53 localhost kernel: FS: 00002aaaaadf2b00(0000)
GS:ffffffff8048e580(0000) knlGS:0000000000000000
May 6 20:16:53 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
May 6 20:16:53 localhost kernel: CR2: 0000000000000030 CR3:
000000003a655000 CR4: 00000000000006e0
May 6 20:16:53 localhost kernel: Process rmmod (pid: 8553, threadinfo
ffff81003b798000, task ffff81003b2b1030)
May 6 20:16:53 localhost kernel: Stack: ffff81003c780830 ffff81003c780800
ffff81003c45f800 ffffffff8825b8fe
May 6 20:16:53 localhost kernel: ffff81003c45f830 ffff81003c45f830
ffff81003c45f800 ffffffff802d63bc
May 6 20:16:53 localhost kernel: 000000013ffc0380 0000000000000296
May 6 20:16:53 localhost kernel: Call
Trace:<ffffffff8825b8fe>{:powernow-k8:powernowk8_cpu_exit+46}
May 6 20:16:53 localhost kernel:
<ffffffff802d63bc>{cpufreq_remove_dev+252}
<ffffffff80291fb9>{sysdev_driver_unregister+121}
May 6 20:16:53 localhost kernel:
<ffffffff802d731f>{cpufreq_unregister_driver+47}
<ffffffff8019efd2>{sys_delete_module+754}
May 6 20:16:53 localhost kernel: <ffffffff801bad36>{do_munmap+854}
<ffffffff801bb6ca>{sys_munmap+90}
May 6 20:16:53 localhost kernel: <ffffffff8010e2b2>{system_call+126}
May 6 20:16:53 localhost kernel:
May 6 20:16:53 localhost kernel: Code: 48 8b 78 30 e8 41 18 07 f8 48 c7 83
00 03 00 00 00 00 00 00
May 6 20:16:53 localhost kernel: RIP
<ffffffff8813ef96>{:processor:acpi_processor_unregister_performance+43} RSP
<ffff81003b799d78>
May 6 20:16:53 localhost kernel: CR2: 0000000000000030
May 6 20:16:53 localhost cpufreq: ÉCHEC
May 6 20:16:53 localhost cpufreq:
May 6 20:16:53 localhost rc: Arrêt de cpufreq : failed
May 6 20:16:53 localhost acpid: Arrêt de acpid succeeded
May 6 20:16:54 localhost atd: Arrêt de atd succeeded
May 6 20:16:54 localhost bluetooth: Arrêt de hciattach failed

Olivier V


Nicolas S.


--
Adresse mail: .net

Avatar
Olivier V
Nicolas S. wrote:

En fait le problème ne vient aparamment pas du SMP.


Je pense que l'usage du SMP pour ce type de processeur ne convient tout
de même pas.


Je suis bien d'accord.
Dans la suite le noyau utilisé sera donc toujours celui sans SMP.

Bien. Il faut savoir que l'implémentation du 64 bits est relativement
récent. Il se peut donc qu'il y ait encore des bugs.
On peut évidemment essayer de chercher plus loin l'origine du problème;
ceci dit, cela demandera beaucoup d'investissement personnel. Un kernel
Oops n'est jamais bon...
Je vous conseille d'utiliser la version 32 bits stable en attendant.


Justement :
Sur la 10.1 version 32 bits dont nous avions parlé, il n'y avait pas
d'implémentation de cpufreq dans le noyau ce qui faisait tourner mon
processeur de manière fixe à 800 MHz ...

Vous m'aviez alors dit de compiler le noyau avec les options adéquates.

Or la 10.1 ne supportait par ailleurs pas tout mon matériel (par exemple pas
ma carte Wifi ...)

J'ai donc préféré installer la 10.2 (qui vient de passer en stable) en
version 32 bits et avec le noyau sans SMP qui intègre cpufreq.

Patatra c'est exactement le problème lors de l'arrêt ...

Donc 32 ou 64 -> même problème.

Mais on peut effectivement dorénavant continuer à chercher sur version 32
bits ?

Si vous voulez aller plus loin,


J'aimerais bien ...

fournissez plus d'info:


Passons donc à la Mandrake 10.2 32 bits :

Deux remarques :
- le problème n'a pas lieu lorsque l'acpi est désactivée.
- tout fonctionne très bien quand la Mandrake tourne : le processeur monte
en puissance tout seul dans le profil "ondemand", etc ...
c'est juste à l'arrêt que c'est le bazard.

# dmesg |grep -i powernow


[ ~]$ dmesg | grep -i powernow
powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e)
powernow-k8: 0 : fid 0x0 (800 MHz), vid 0x12 (1100 mV)
powernow-k8: 1 : fid 0xa (1800 MHz), vid 0xe (1200 mV)
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
powernow-k8: 3 : fid 0xe (2200 MHz), vid 0x6 (1400 mV)
powernow-k8: 4 : fid 0x10 (2400 MHz), vid 0x2 (1500 mV)

# dmesg |grep -i cpu


[ ~]$ dmesg | grep -i cpu
CPU: After generic identify, caps: 078bfbff e1d3fbff 00000000 00000000
0000000000000000 00000000
CPU: After vendor identify, caps: 078bfbff e1d3fbff 00000000 00000000
00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: After all inits, caps: 078bfbff e1d3fbff 00000000 00000010 00000000
00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) 64 Processor 3700+ stepping 0a
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
cpu_init done, current fid 0x0, vid 0x12

# cat /proc/acpi/processor/CPU0/power


[ ~]$ cat /proc/acpi/processor/CPU1/power
active state: C2
max_cstate: C8
bus master activity: 023eeeb0
states:
C1: type[C1] promotion[C2] demotion[--] latency[000]
usage[00000010]
*C2: type[C2] promotion[C3] demotion[C1] latency[080]
usage[139012646]
C3: type[C3] promotion[--] demotion[C2] latency[800]
usage[00031291]

# cat /proc/acpi/processor/CPU0/info


il n'y a pas de CPU0, mais un CPU1

[ ~]$ cat /proc/acpi/processor/CPU1/info
processor id: 0
acpi id: 1
bus mastering control: yes
power management: yes
throttling control: no
limit interface: no

# cat /proc/cpuinfo


[ ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 4
model name : AMD Athlon(tm) 64 Processor 3700+
stepping : 10
cpu MHz : 1796.379
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmovpat pse36 clflush mmx fxsr sse sse2 pni syscall nx mmxext lm 3dnowext
3dnow
bogomips : 3566.59

J'essaierais alors de voir s'il s'agit d'un bug connu.


Olivier V


Avatar
Olivier V
Pour mémoire et éviter d'aller chercher 20 messages avant, je re-poste les
erreurs lors de l'arrêt pour la version 32 bits.

Vous trouverez en dessous le démarrage ... ou tout est OK.

May 7 19:33:48 localhost cpufreqd: Arrêt de cpufreqd succeeded
May 7 19:33:48 localhost cpufreq: Déchargement des modules cpufreq :
May 7 19:33:48 localhost kernel: Unable to handle kernel NULL pointer
dereference at virtual address 0000002c
May 7 19:33:48 localhost kernel: printing eip:
May 7 19:33:48 localhost kernel: f8fc4f14
May 7 19:33:48 localhost kernel: *pde = 37532001
May 7 19:33:48 localhost kernel: Oops: 0000 [#1]
May 7 19:33:48 localhost kernel: Modules linked in: nls_iso8859-1 nls_cp437
cpufreq_ondemand powernow-k8 raw md5 ipv6 rfcomm l2cap bluetooth
snd-seq-dummy snd-seq-oss snd-seq-midi-event snd-seq snd-seq-device
snd-pcm-oss snd-mixer-oss snd-intel8x0 snd-ac97-codec snd-pcm snd-timer
snd-page-alloc snd soundcore af_packet pcmcia yenta_socket rsrc_nonstatic
pcmcia_core video thermal tc1100-wmi processor fan container button battery
ac eth1394 sis900 ide-cd ohci1394 ieee1394 loop nls_cp850 vfat fat
nls_iso8859-15 ntfs sis-agp amd64-agp agpgart nvram evdev sd_mod
usb-storage scsi_mod ehci-hcd ohci-hcd usbcore ext3 jbd
May 7 19:33:48 localhost kernel: CPU: 0
May 7 19:33:48 localhost kernel: EIP: 0060:[pg0+951295764/1068971008]
Not tainted VLI
May 7 19:33:48 localhost kernel: EIP: 0060:[<f8fc4f14>] Not tainted
VLI
May 7 19:33:48 localhost kernel: EFLAGS: 00010286 (2.6.11-6mdk)
May 7 19:33:48 localhost kernel: EIP is at
acpi_processor_unregister_performance+0x24/0x48 [processor]
May 7 19:33:48 localhost kernel: eax: 00000000 ebx: f79ac000 ecx:
f8c3d280 edx: f76d7880
May 7 19:33:48 localhost kernel: esi: f7583d80 edi: f7583dfc ebp:
f77fbe50 esp: f77fbe4c
May 7 19:33:48 localhost cpufreq: /etc/rc0.d/K35cpufreq: line 199: 13411
Segmentation fault rmmod $MODULE 2>/dev/null
May 7 19:33:48 localhost cpufreq: failed
May 7 19:33:48 localhost kernel: ds: 007b es: 007b ss: 0068
May 7 19:33:48 localhost cpufreq: ^[[65G[^[[1;31m
May 7 19:33:48 localhost kernel: Process rmmod (pid: 13411,
threadinfo÷7fa000 task÷079570)
May 7 19:33:48 localhost kernel: Stack: f76d7880 f77fbe60 f8c3cfc3 f76d78ac
00000000 f77fbe74 f8c3d2aa f76d7880
May 7 19:33:48 localhost kernel: f7583d80 00000002 f77fbe90 c02cdfae
f7583d80 00000002 c0434d88 c03b7918
May 7 19:33:48 localhost kernel: c03b19fc f77fbea8 c0280d78 c0434d88
f8c3d360 f8c3e920 00000000 f77fbeb8
May 7 19:33:48 localhost kernel: Call Trace:
May 7 19:33:48 localhost kernel: [show_stack+127/160] show_stack+0x7f/0xa0
May 7 19:33:48 localhost kernel: [<c0103c4f>] show_stack+0x7f/0xa0
May 7 19:33:48 localhost kernel: [show_registers+342/464]
show_registers+0x156/0x1d0
May 7 19:33:48 localhost kernel: [<c0103de6>] show_registers+0x156/0x1d0
May 7 19:33:48 localhost kernel: [die+200/336] die+0xc8/0x150
May 7 19:33:48 localhost kernel: [<c0103fe8>] die+0xc8/0x150
May 7 19:33:48 localhost kernel: [do_page_fault+1146/1818]
do_page_fault+0x47a/0x71a
May 7 19:33:48 localhost kernel: [<c011637a>] do_page_fault+0x47a/0x71a
May 7 19:33:48 localhost kernel: [error_code+43/48] error_code+0x2b/0x30
May 7 19:33:48 localhost kernel: [<c01038eb>] error_code+0x2b/0x30
May 7 19:33:48 localhost kernel: [pg0+947593155/1068971008]
powernow_k8_cpu_exit_acpi+0x23/0x30 [powernow-k8]
May 7 19:33:48 localhost kernel: [<f8c3cfc3>]
powernow_k8_cpu_exit_acpi+0x23/0x30 [powernow-k8]
May 7 19:33:48 localhost kernel: [pg0+947593898/1068971008]
powernowk8_cpu_exit+0x2a/0x60 [powernow-k8]
May 7 19:33:48 localhost kernel: [<f8c3d2aa>]
powernowk8_cpu_exit+0x2a/0x60 [powernow-k8]
May 7 19:33:48 localhost kernel: [cpufreq_remove_dev+206/240]
cpufreq_remove_dev+0xce/0xf0
May 7 19:33:48 localhost kernel: [<c02cdfae>] cpufreq_remove_dev+0xce/0xf0
May 7 19:33:48 localhost kernel: [sysdev_driver_unregister+104/176]
sysdev_driver_unregister+0x68/0xb0
May 7 19:33:48 localhost kernel: [<c0280d78>]
sysdev_driver_unregister+0x68/0xb0
May 7 19:33:48 localhost kernel: [cpufreq_unregister_driver+48/65]
cpufreq_unregister_driver+0x30/0x41
May 7 19:33:48 localhost kernel: [<c02ceab0>]
cpufreq_unregister_driver+0x30/0x41
May 7 19:33:48 localhost kernel: [pg0+947594098/1068971008]
powernowk8_exit+0x12/0x14 [powernow-k8]
May 7 19:33:48 localhost kernel: [<f8c3d372>] powernowk8_exit+0x12/0x14
[powernow-k8]
May 7 19:33:48 localhost kernel: [sys_delete_module+588/608]
sys_delete_module+0x24c/0x260
May 7 19:33:48 localhost kernel: [<c0188bdc>]
sys_delete_module+0x24c/0x260
May 7 19:33:48 localhost kernel: [sysenter_past_esp+82/117]
sysenter_past_esp+0x52/0x75
May 7 19:33:48 localhost kernel: [<c0102e5d>] sysenter_past_esp+0x52/0x75
May 7 19:33:48 localhost kernel: Code: 31 c0 8b 5d fc c9 c3 55 89 e5 53 ff
0d 4c 75 fc f8 0f 88 a8 00 00 00 8b 45 0c 8b 1c 85 c4 76 fc f8 85 db 74 19
8b 83 6c 02 00 00 <ff> 70 2c e8 f4 59 1d c7 c7 83 6c 02 00 00 00 00 00 00
59 ff 05
May 7 19:33:48 localhost cpufreq: ÉCHEC
May 7 19:33:48 localhost cpufreq:
May 7 19:33:48 localhost rc: Arrêt de cpufreq : failed


AU DEMARRAGE :

May 7 19:13:54 localhost cpufreq: Chargement des modules cpufreq :
May 7 19:13:54 localhost kernel: powernow-k8: Found 1 AMD Athlon 64 /
Opteron processors (version 1.00.09e)
May 7 19:13:54 localhost kernel: powernow-k8: 0 : fid 0x0 (800 MHz), vid
0x12 (1100 mV)
May 7 19:13:54 localhost kernel: powernow-k8: 1 : fid 0xa (1800 MHz),
vid 0xe (1200 mV)
May 7 19:13:54 localhost kernel: powernow-k8: 2 : fid 0xc (2000 MHz),
vid 0xa (1300 mV)
May 7 19:13:54 localhost kernel: powernow-k8: 3 : fid 0xe (2200 MHz),
vid 0x6 (1400 mV)
May 7 19:13:54 localhost kernel: powernow-k8: 4 : fid 0x10 (2400 MHz),
vid 0x2 (1500 mV)
May 7 19:13:54 localhost kernel: cpu_init done, current fid 0x0, vid 0x12
May 7 19:13:55 localhost fstab-sync[6289]: added mount point /mnt/floppy5
for /dev/sdc

Olivier V
Avatar
Nicolas S.

Dans la suite le noyau utilisé sera donc toujours celui sans SMP.


Ok.

Je vous conseille d'utiliser la version 32 bits stable en attendant.


Justement :
Sur la 10.1 version 32 bits dont nous avions parlé, il n'y avait pas
d'implémentation de cpufreq dans le noyau ce qui faisait tourner mon
processeur de manière fixe à 800 MHz ...


Sur mon portable avec mdk 10.1, le noyau par défault contient pourtant
le cpufreq! Je ne peux cependant pas tout tester car ma batterie est HS. :-(


Vous m'aviez alors dit de compiler le noyau avec les options adéquates.

Or la 10.1 ne supportait par ailleurs pas tout mon matériel (par exemple pas
ma carte Wifi ...)

J'ai donc préféré installer la 10.2 (qui vient de passer en stable) en
version 32 bits et avec le noyau sans SMP qui intègre cpufreq.

Patatra c'est exactement le problème lors de l'arrêt ...

Donc 32 ou 64 -> même problème.

Mais on peut effectivement dorénavant continuer à chercher sur version 32
bits ?


Oui. Je pense qu'il vaut mieux régler les problèmes sur la version 32
bits avant de passer en 64 bits. On verra alors plus précisément les
problèmes. (ceux en 32 bits étant bien connus).


Si vous voulez aller plus loin,


J'aimerais bien ...

Allons-y!



fournissez plus d'info:



Passons donc à la Mandrake 10.2 32 bits :

Deux remarques :
- le problème n'a pas lieu lorsque l'acpi est désactivée.
- tout fonctionne très bien quand la Mandrake tourne : le processeur monte
en puissance tout seul dans le profil "ondemand", etc ...
c'est juste à l'arrêt que c'est le bazard.


Je me replongerai là dedans très prochainement. Si ce n'est pas fait ce
soir, ce le sera sûrement demain.
J'ai oublié de vous demander la version excacte de votre noyau (# uname
-a). J'irais télécharger les sources pour être sûr de travailler sur le
même code.



# dmesg |grep -i powernow



[ ~]$ dmesg | grep -i powernow
powernow-k8: Found 1 AMD Athlon 64 / Opteron processors (version 1.00.09e)
powernow-k8: 0 : fid 0x0 (800 MHz), vid 0x12 (1100 mV)
powernow-k8: 1 : fid 0xa (1800 MHz), vid 0xe (1200 mV)
powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xa (1300 mV)
powernow-k8: 3 : fid 0xe (2200 MHz), vid 0x6 (1400 mV)
powernow-k8: 4 : fid 0x10 (2400 MHz), vid 0x2 (1500 mV)


# dmesg |grep -i cpu



[ ~]$ dmesg | grep -i cpu
CPU: After generic identify, caps: 078bfbff e1d3fbff 00000000 00000000
0000000000000000 00000000
CPU: After vendor identify, caps: 078bfbff e1d3fbff 00000000 00000000
00000000 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 1024K (64 bytes/line)
CPU: After all inits, caps: 078bfbff e1d3fbff 00000000 00000010 00000000
00000000 00000000
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) 64 Processor 3700+ stepping 0a
ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
cpu_init done, current fid 0x0, vid 0x12


# cat /proc/acpi/processor/CPU0/power



[ ~]$ cat /proc/acpi/processor/CPU1/power
active state: C2
max_cstate: C8
bus master activity: 023eeeb0
states:
C1: type[C1] promotion[C2] demotion[--] latency[000]
usage[00000010]
*C2: type[C2] promotion[C3] demotion[C1] latency[080]
usage[139012646]
C3: type[C3] promotion[--] demotion[C2] latency[800]
usage[00031291]


# cat /proc/acpi/processor/CPU0/info



il n'y a pas de CPU0, mais un CPU1

[ ~]$ cat /proc/acpi/processor/CPU1/info
processor id: 0
acpi id: 1
bus mastering control: yes
power management: yes
throttling control: no
limit interface: no


# cat /proc/cpuinfo



[ ~]$ cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 4
model name : AMD Athlon(tm) 64 Processor 3700+
stepping : 10
cpu MHz : 1796.379
cache size : 1024 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmovpat pse36 clflush mmx fxsr sse sse2 pni syscall nx mmxext lm 3dnowext
3dnow
bogomips : 3566.59


J'essaierais alors de voir s'il s'agit d'un bug connu.



Olivier V



Nicolas S.

--
Adresse mail: .net


Avatar
Olivier V
Nicolas S. wrote:

Sur mon portable avec mdk 10.1, le noyau par défault contient pourtant
le cpufreq!


Vous avez sans doute raison. J'ai dû m'embrouiller.

Si vous le souhaitez, je peux revenir à la 10.1.

Je ne peux cependant pas tout tester car ma batterie est HS.
:-(


En fait, tous les essais faits jusqu'à présent sont effectués sans batterie.

Je me replongerai là dedans très prochainement. Si ce n'est pas fait ce
soir, ce le sera sûrement demain.
J'ai oublié de vous demander la version excacte de votre noyau (# uname
-a). J'irais télécharger les sources pour être sûr de travailler sur le
même code.


[ ~]$ uname -a
Linux localhost 2.6.11-6mdk #1 Tue Mar 22 16:04:32 CET 2005 i686 AMD
Athlon(tm)64 Processor 3700+ unknown GNU/Linux

Et un lien vers ces noyaux :

ftp://ftp.ciril.fr/pub/linux/mandrakelinux/official/2005/i586/media/main/kernel-2.6.11.6mdk-1-1mdk.i586.rpm
ftp://ftp.ciril.fr/pub/linux/mandrakelinux/official/2005/i586/media/main/kernel-source-2.6-2.6.11-6mdk.i586.rpm

J'essaierais alors de voir s'il s'agit d'un bug connu.



Oui. Je pense qu'il vaut mieux régler les problèmes sur la version 32
bits avant de passer en 64 bits. On verra alors plus précisément les
problèmes. (ceux en 32 bits étant bien connus).


J'ai lancé un fil en anglais :
http://groups.google.fr/group/comp.os.linux.portable/browse_thread/thread/8e42a3f5eb7ff5a2/531a2d9209e2b3ae?hl=fr#531a2d9209e2b3ae

On me dit que c'est un bug connu, mais je n'ai pas trouvé où :

It is no wonder you have problems. You have a kernel "crash" (well oops) on
trying to load the cpufreq module. The 2.6 kernels have had problems.. I
know that the 2.6.8 kenrels did, and there is a Mandrake bug which
discusses this and has a suggested solution. It was my bug, but at
present I cannot get at the bugs list to look it up. But a search on
qa.mandrake.com could give a hint.

Ou d'utiliser le noyau 2.4, ce qui me fera sans doute galérer pou ma carte
Wifi :

I wonder if a drop back to 2.4 would solve the problem?? I've had all
sorts of ACPI problems on my Latitude with 2.6.x, dropping back to 2.4
loses /some/ functionality (pretty much just the support features added
in 2.6.x), but overall it works just fine.

Olivier V



1 2 3