Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle version du système ? Que donne "top" ?
MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long" qq part dans le code :)
Eric Levenez
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$, « Olivier Croquette » a écrit :
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle version du système ? Que donne "top" ?
MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long" qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
D'après ce que je comprends la fonction task_info du noyau est différente sur un CPU intel 32 et 64 bits. En 32 bits (je suppose que c'est ce que tu as vu que tu n'en parles pas), la taille mémoire est stockée dans un "unsigned int" (si l'on se réfère aux includes), ce qui n'est pas bon car avec 4 Go de RAM, on obtiendrait 0. Mais d'un autre côté à d'autres endroits du noyau cette taille est calculée en page, donc, aucun problème, si c'est bien fait. Avec un CPU 64 bits, pas de problème car les calculs sont faits en 64 bits non signés. La commande ps, elle, fait une conversion de ces nombres non signés en flottants pour affichage, alors je ne pense pas que le bug soit dans "ps".
Bref, le mieux est de faire un bug report, car eux auront le temps de trouver le problème...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$1@news.t-online.com>, « Olivier
Croquette » <ocroquette@ocroquette.free.fr> a écrit :
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle
version du système ? Que donne "top" ?
MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long"
qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
D'après ce que je comprends la fonction task_info du noyau est différente
sur un CPU intel 32 et 64 bits. En 32 bits (je suppose que c'est ce que tu
as vu que tu n'en parles pas), la taille mémoire est stockée dans un
"unsigned int" (si l'on se réfère aux includes), ce qui n'est pas bon car
avec 4 Go de RAM, on obtiendrait 0. Mais d'un autre côté à d'autres endroits
du noyau cette taille est calculée en page, donc, aucun problème, si c'est
bien fait. Avec un CPU 64 bits, pas de problème car les calculs sont faits
en 64 bits non signés. La commande ps, elle, fait une conversion de ces
nombres non signés en flottants pour affichage, alors je ne pense pas que le
bug soit dans "ps".
Bref, le mieux est de faire un bug report, car eux auront le temps de
trouver le problème...
--
Éric Lévénez -- <http://www.levenez.com/>
Unix is not only an OS, it's a way of life.
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$, « Olivier Croquette » a écrit :
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle version du système ? Que donne "top" ?
MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long" qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
D'après ce que je comprends la fonction task_info du noyau est différente sur un CPU intel 32 et 64 bits. En 32 bits (je suppose que c'est ce que tu as vu que tu n'en parles pas), la taille mémoire est stockée dans un "unsigned int" (si l'on se réfère aux includes), ce qui n'est pas bon car avec 4 Go de RAM, on obtiendrait 0. Mais d'un autre côté à d'autres endroits du noyau cette taille est calculée en page, donc, aucun problème, si c'est bien fait. Avec un CPU 64 bits, pas de problème car les calculs sont faits en 64 bits non signés. La commande ps, elle, fait une conversion de ces nombres non signés en flottants pour affichage, alors je ne pense pas que le bug soit dans "ps".
Bref, le mieux est de faire un bug report, car eux auront le temps de trouver le problème...
-- Éric Lévénez -- <http://www.levenez.com/> Unix is not only an OS, it's a way of life.
Anonyme
Eric Levenez wrote:
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$, « Olivier Croquette » a écrit :
> Eric Levenez wrote, On 7/12/08 12:52: >> Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle >> version du système ? Que donne "top" ? > > MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long" > qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
Attention toute fois à s'assurer que le MBP en question est bien sensé supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go selon Apple...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Eric Levenez <usenet@levenez.com> wrote:
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$1@news.t-online.com>, « Olivier
Croquette » <ocroquette@ocroquette.free.fr> a écrit :
> Eric Levenez wrote, On 7/12/08 12:52:
>> Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle
>> version du système ? Que donne "top" ?
>
> MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long"
> qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
Attention toute fois à s'assurer que le MBP en question est bien sensé
supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go
selon Apple...
--
Anonyme ( jayce <@> mosx.org )
********* MosX.org <http://www.mosx.org/> *********
Ce message est sous licence Creative Commons "by-nc-sa-2.0"
<http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$, « Olivier Croquette » a écrit :
> Eric Levenez wrote, On 7/12/08 12:52: >> Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle >> version du système ? Que donne "top" ? > > MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long" > qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
Attention toute fois à s'assurer que le MBP en question est bien sensé supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go selon Apple...
-- Anonyme ( jayce <@> mosx.org ) ********* MosX.org <http://www.mosx.org/> ********* Ce message est sous licence Creative Commons "by-nc-sa-2.0" <http://creativecommons.org/licenses/by-nc-sa/2.0/fr/>
fx [François-Xavier Peretmere]
On 08/12/2008 12:50, Anonyme wrote:
Eric Levenez wrote:
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$, « Olivier Croquette » a écrit :
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle version du système ? Que donne "top" ?
MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long" qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
Attention toute fois à s'assurer que le MBP en question est bien sensé supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go selon Apple...
Exact. Mais normalement, les Go supplémentaires sont simplement ignorés - du moins c'est ce que j'avais lu à l'époque. Je n'ai pas testé, j'ai acheté une barrette de 1 Go du coup.
Je ne pense pas que cela expliquerait la mémoire négative. Bien qu'il suffirait d'en ôter une pour tester.
-- Fx, quatriéme jour sans MBP. It's a hard life without the little retarded.
On 08/12/2008 12:50, Anonyme wrote:
Eric Levenez <usenet@levenez.com> wrote:
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$1@news.t-online.com>, « Olivier
Croquette » <ocroquette@ocroquette.free.fr> a écrit :
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle
version du système ? Que donne "top" ?
MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long"
qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
Attention toute fois à s'assurer que le MBP en question est bien sensé
supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go
selon Apple...
Exact. Mais normalement, les Go supplémentaires sont simplement ignorés - du
moins c'est ce que j'avais lu à l'époque. Je n'ai pas testé, j'ai acheté une
barrette de 1 Go du coup.
Je ne pense pas que cela expliquerait la mémoire négative. Bien qu'il suffirait
d'en ôter une pour tester.
--
Fx, quatriéme jour sans MBP. It's a hard life without the little retarded.
Le 07/12/08 19:15, dans <ghh3sf$l9s$03$, « Olivier Croquette » a écrit :
Eric Levenez wrote, On 7/12/08 12:52:
Sûr que c'est un bug. C'est quoi comme machine ? Combien de RAM ? Quelle version du système ? Que donne "top" ?
MBP, 4Go. Sûrement un "long" qui devrait plutôt être un "unsigned long" qq part dans le code :)
Il faudrait, bien entendu, faire un bug report à Apple.
Attention toute fois à s'assurer que le MBP en question est bien sensé supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go selon Apple...
Exact. Mais normalement, les Go supplémentaires sont simplement ignorés - du moins c'est ce que j'avais lu à l'époque. Je n'ai pas testé, j'ai acheté une barrette de 1 Go du coup.
Je ne pense pas que cela expliquerait la mémoire négative. Bien qu'il suffirait d'en ôter une pour tester.
-- Fx, quatriéme jour sans MBP. It's a hard life without the little retarded.
Olivier Croquette
Anonyme wrote, On 8/12/08 12:50:
Attention toute fois à s'assurer que le MBP en question est bien sensé supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go selon Apple...
Oui, c'est un MBP mid 2007. Version du système : Mac OS X 10.4.11 (8S2167) Version du noyau : Darwin 8.11.1
Anonyme wrote, On 8/12/08 12:50:
Attention toute fois à s'assurer que le MBP en question est bien sensé
supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go
selon Apple...
Oui, c'est un MBP mid 2007.
Version du système : Mac OS X 10.4.11 (8S2167)
Version du noyau : Darwin 8.11.1
Attention toute fois à s'assurer que le MBP en question est bien sensé supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go selon Apple...
Oui, c'est un MBP mid 2007. Version du système : Mac OS X 10.4.11 (8S2167) Version du noyau : Darwin 8.11.1
manet
"fx [François-Xavier Peretmere]" wrote:
> Attention toute fois à s'assurer que le MBP en question est bien sensé > supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go > selon Apple...
Exact. Mais normalement, les Go supplémentaires sont simplement ignorés -
il faudrait savoir comment le chipset fonctionne.
d'après ce que j'ai lu, quand on met d 2 x 2 G sur les machines dont le chipset Intel est limité à 3G - sur Tiger, le système voit 3G - sur Leo, le système en voit 4.
mais dans tous les cas, le système ne sait pas allouer plus de 3,xxx G, avec xxx du coté de 600 MO ou 000 selon les sources
cependant, on bénéficie de la parité des barrettes, qui accélére le transfert RAM. Le processeur ne sachant pas bénéfiier de cette parité, ce serait uniquement le processeur graphique (qui utilise la RAM) qui gagnerait en vitesse ; le bénéfice dépend donc largement du type d'utilisation.
Les tests de base trouvent 3 à 5% en mieux (3G vs 4G) sur OWC, si je me souviens bien.
> Attention toute fois à s'assurer que le MBP en question est bien sensé
> supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go
> selon Apple...
Exact. Mais normalement, les Go supplémentaires sont simplement ignorés -
il faudrait savoir comment le chipset fonctionne.
d'après ce que j'ai lu, quand on met d 2 x 2 G sur les machines dont le
chipset Intel est limité à 3G
- sur Tiger, le système voit 3G
- sur Leo, le système en voit 4.
mais dans tous les cas, le système ne sait pas allouer plus de 3,xxx G,
avec xxx du coté de 600 MO ou 000 selon les sources
cependant, on bénéficie de la parité des barrettes, qui accélére le
transfert RAM. Le processeur ne sachant pas bénéfiier de cette parité,
ce serait uniquement le processeur graphique (qui utilise la RAM) qui
gagnerait en vitesse ; le bénéfice dépend donc largement du type
d'utilisation.
Les tests de base trouvent 3 à 5% en mieux (3G vs 4G) sur OWC, si je me
souviens bien.
> Attention toute fois à s'assurer que le MBP en question est bien sensé > supporter 4Go... Les derniers oui, ceux d'avant ne supportaient que 3Go > selon Apple...
Exact. Mais normalement, les Go supplémentaires sont simplement ignorés -
il faudrait savoir comment le chipset fonctionne.
d'après ce que j'ai lu, quand on met d 2 x 2 G sur les machines dont le chipset Intel est limité à 3G - sur Tiger, le système voit 3G - sur Leo, le système en voit 4.
mais dans tous les cas, le système ne sait pas allouer plus de 3,xxx G, avec xxx du coté de 600 MO ou 000 selon les sources
cependant, on bénéficie de la parité des barrettes, qui accélére le transfert RAM. Le processeur ne sachant pas bénéfiier de cette parité, ce serait uniquement le processeur graphique (qui utilise la RAM) qui gagnerait en vitesse ; le bénéfice dépend donc largement du type d'utilisation.
Les tests de base trouvent 3 à 5% en mieux (3G vs 4G) sur OWC, si je me souviens bien.
laurent.pertois
Philippe Manet wrote:
ce serait uniquement le processeur graphique (qui utilise la RAM) qui gagnerait en vitesse ; le bénéfice dépend donc largement du type d'utilisation.
Pas sur un MacBook Pro qui a une carte graphique (encore que pour les derniers il faut voir vu que ce dernier a 2 systèmes)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Philippe Manet <manet@invivo.edu> wrote:
ce serait uniquement le processeur graphique (qui utilise la RAM) qui
gagnerait en vitesse ; le bénéfice dépend donc largement du type
d'utilisation.
Pas sur un MacBook Pro qui a une carte graphique (encore que pour les
derniers il faut voir vu que ce dernier a 2 systèmes)
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
ce serait uniquement le processeur graphique (qui utilise la RAM) qui gagnerait en vitesse ; le bénéfice dépend donc largement du type d'utilisation.
Pas sur un MacBook Pro qui a une carte graphique (encore que pour les derniers il faut voir vu que ce dernier a 2 systèmes)
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Olivier Croquette
Olivier Croquette wrote, On 7/12/08 12:07:
mbp:~ ocroquette$ ps aux | head USER PID %CPU %MEM VSZ RSS TT STAT TIME COMMAND windowse 90 1.7 -2.4 442200 51088 ?? Ss 0:55.92 /System/L
J'ai pas cherché la cause, mais il doit y avoir un bug qqpart...
Pour info, la réponse d'Apple:
This is a follow up to Bug ID# 6426376. After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 3118432. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs.
Olivier Croquette wrote, On 7/12/08 12:07:
mbp:~ ocroquette$ ps aux | head
USER PID %CPU %MEM VSZ RSS TT STAT TIME COMMAND
windowse 90 1.7 -2.4 442200 51088 ?? Ss 0:55.92 /System/L
J'ai pas cherché la cause, mais il doit y avoir un bug qqpart...
Pour info, la réponse d'Apple:
This is a follow up to Bug ID# 6426376. After further investigation it
has been determined that this is a known issue, which is currently being
investigated by engineering. This issue has been filed in our bug
database under the original Bug ID# 3118432. The original bug number
being used to track this duplicate issue can be found in the State
column, in this format: Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your
assistance in helping us discover and isolate bugs.
mbp:~ ocroquette$ ps aux | head USER PID %CPU %MEM VSZ RSS TT STAT TIME COMMAND windowse 90 1.7 -2.4 442200 51088 ?? Ss 0:55.92 /System/L
J'ai pas cherché la cause, mais il doit y avoir un bug qqpart...
Pour info, la réponse d'Apple:
This is a follow up to Bug ID# 6426376. After further investigation it has been determined that this is a known issue, which is currently being investigated by engineering. This issue has been filed in our bug database under the original Bug ID# 3118432. The original bug number being used to track this duplicate issue can be found in the State column, in this format: Duplicate/OrigBug#.
Thank you for submitting this bug report. We truly appreciate your assistance in helping us discover and isolate bugs.
