Bug d'autonomie des Core duo, le point, Réactions à la news du 14-02-2006

[Lionel]

A plusieurs reprises nous vous avons relaté les soucis d'autonomie des portables à base de Core Duo (ici et là). En résumé, le simple fait de brancher un périphérique USB sur ces machine, leur ferait perdre environ 30% de la durée de fonctionnement sur batteries.
AnandTech revient sur le sujet et apporte de nouvelles informations.
-Tout d'abord, ce bug n'est pas propre aux machines à base de Yonah, mais globalement à tous les portables à base de Pentium M.
- Ce bug se manifeste dès que l'on branche un périphérique USB, même si ce dernier n'est pas en fonctionnement. Concrètement, il bloque le fonctionnement des systèmes d'économie d'énergie à la consommation la plus élevée, et ce, inutilement.
- Microsoft a publié pour Windows XP un patch qui résout partiellement le problème en attendant une solution plus définitive. S'il permet de récupérer l'autonomie perdue, il n'est pas parfait. Certains ordinateurs n'y sont pas sensibles, et une mise en veille de la machine le désactive. Il faut lors redémarrer pour en retrouver l'effet.

C'est malgré tout une bonne nouvelle, puisqu'il semble possible de contourner ce soucis matériel par voie logicielle. On peut-être certain qu'Apple s'y applique et que bientôt nous pourrons connaître l'autonomie théorique des MacBook Pro.

[dominik]

Quoiqu'il en soit, tout cela fait un peu "Mr Bricolage"
C'est franchement navrant pour une nouvelle gamme et surtout pour ceux qui se sont risqués à investir dans un MacIntel portable.

[Hakime]

Mais attendez vous savez pas lire l'amglais ou quoi.

Leut test montre une chose, et une seule c'est que le bug apparait avec les drivers USB 2.0 de Windows xp2, car leur driver semble executer le scheduler tous le temps. Le fait qu'une solution (ce n'est pas un patch comme vous le dites mais une manipiulation dans les registres de windows) proposee par Microsoft ressoud en partie le probleme est une preuve de la responsabilite de windows dans ce bug. Si le bug serait hardware la manipulation de Microsoft ne marcherait pas.

Apple n'a absolulment rien a voir avec cela, et n'est absolument pas concerne par le bug decrit par Anandtech. Il faudrait quand meme faire attention a ce que vous ecrivez, car votre manie de toujours chercher le moindre probleme avec Apple vous fait dire des grosses conneries. Ou alors lisez correctement la source avant de publier votre news, c'est enervant de lire des conneries comme cela.

Ce que vous faite la c'est de la desinformation rien de plus....

[benja]

Il est vrai qu'Intel semblait rejeter toute la responsabilité de ce bug sur Microsoft alors que cette news semble accuser Intel... Mais je suis sur que nous saurons très vite qui est le vrai responsable, en tout cas ça reste inquiétant qu'Apple n'ait communiqué aucun chiffre sur l'autonomie des MacBook Pro...

[dreamph]

Mais attendez vous savez pas lire l'amglais ou quoi.

Leut test montre une chose, et une seule c'est que le bug apparait avec les drivers USB 2.0 de Windows xp2, car leur driver semble executer le scheduler tous le temps. Le fait qu'une solution (ce n'est pas un patch comme vous le dites mais une manipiulation dans les registres de windows) proposee par Microsoft ressoud en partie le probleme est une preuve de la responsabilite de windows dans ce bug. Si le bug serait hardware la manipulation de Microsoft ne marcherait pas.

Apple n'a absolulment rien a voir avec cela, et n'est absolument pas concerne par le bug decrit par Anandtech. Il faudrait quand meme faire attention a ce que vous ecrivez, car votre manie de toujours chercher le moindre probleme avec Apple vous fait dire des grosses conneries. Ou alors lisez correctement la source avant de publier votre news, c'est enervant de lire des conneries comme cela.

Ce que vous faite la c'est de la desinformation rien de plus....

Wow, molo molo
N'empêche qu'on a toujours pas de données officielles sur l'autonomie. Et ça c'est du concret.

Ce message a été modifié par dreamph - 14 Feb 2006, 10:33.

[Lionel]

Laisse tomber. Lorsque j'ai rédigé la brève, je me suis dit, Tiens, Hakime va gueuler un coup.

[tasdu]

Tiens ca me rappel un sujet recent ... des cobayes !! -)

[frcs]

C'est quoi l'autonomie du macbook déjà ????

[stephane36]

Mon avis : si le problème était uniquement lié à Windows, j'imagine que MS l'aurait réglé il y a longtemps. Ils ne sont pas maso non-plus. Maintenant, que le bug soit dû à une incompatibilité entre le pilote MS et le chipset de gestion de l'USB 2 me parait logique. Or, l'incompatibilité, c'est comme les disputes, faut être deux pour que ça foire...

Rien ne nous dit qu'Apple ne rencontre pas le même souci et doive procéder aux mêmes aménagements dans ses pilotes d'USB2 spécifiquement pour ce chipset Intel dont les spécifications sont peut-être trop restrictives ou mal documentées ou etc. etc.
C'est un peu comme les histoires de la RAM à la quelle Mac OS X était trop sensible : le problème vient-il de Mac OS X ou de la carte-mère ou de la RAM ?

J'imagine qu'Apple, conscient de l'enjeu, s'arrangera pour vaincre se bug à tout prix avant la sortie du MBP dans le commerce si OS X rencontre les mêmes problèmes que Windows mais le silence sur l'autonomie des batteries laisse quand même entendre (sic) que tout n'était pas finalisé au sujet de l'autonomie au moment de la présentation publique du MBP.

On peut espérer qu'Apple, profitant d'une faiblesse en autonomie des PC Core Duo, en a profité pour travailler son avantage pendant un mois et creuser l'écart à la commercialisation des MBP, sait-on jamais...

[markov]

Question bete pourquoi personne ne teste avec un autre systeme d'exploitation ? (linux me semble t-il gere bien la mise en veille) Si c'est logiciel (en assumant que l'implementation USB de linux n'est pas buggué) alors il ne drevait pas y avoir de probleme... Sinon c'est que c'est aussi materiel...Mais bon connaissant un peu les gens de chez intel s'ils avaient un bug dans ce genre j'ose croire qu'il aurait resolue depuis le temps...

[Hervé]

Mais attendez vous savez pas lire l'amglais ou quoi.

La nouvelle langue de l'Amglabonnie ?

[stephane36]

C'est quoi l'autonomie du macbook déjà ????

Selon les commerciaux Apple et quelques déclarations de cadres Apple, elle est comme pour le PB G4 (càd 5h30 théoriques) et selon une poignée de visiteurs du MWSF, il y avait 2h30/3h indiqué dans la barre de menu des machines de pré-production, sans garantie de l'info.

Tiens ca me rappel un sujet recent ... des cobayes !! -)

Tiens ça me rappelle un post où je trouvais insultant de traiter de manière renouvelée les premiers utilisateurs de cobayes au motif qu'ils choisissaient une rev. A.
On peut leur souhaiter bien du courage, leur dire qu'on préfère ne pas faire pareil, leur demander leurs premières impressions, peser le pour et le contre ou discuter des mérites/défauts du passage sous Intel. Mais balancer deux "vive les cobays !" bien sentis dans la même phrase, ça relève de la trollite aigüe à mon avis.

Donc, si tu pouvais nous laisser entre gens civilisés, merci

[Pierre Fracasse]

Je suis impatient que Microsoft sorte ce patch en Universal binaries ;-)

[matcauthron]

Question bete pourquoi personne ne teste avec un autre systeme d'exploitation ? (linux me semble t-il gere bien la mise en veille)

L'idée est bonne, mais malheureusement Linux ne gère pas si bien que ça l'ACPI et la mise en veille. C'est très aléatoire, d'une version à l'autre du noyau, d'un chipset à l'autre...

Il serait donc difficile de conclure sur un test avec Linux.

[unreal]

Laisse tomber. Lorsque j'ai rédigé la brève, je me suis dit, Tiens, Hakime va gueuler un coup.

Je viens de lire l'article d'AnandTech en détail et c'est très clair que le bug vient du driver USB2 de Windows XP :

Windows XP SP2 installs a USB 2.0 driver that initializes any connected USB device. However, the USB 2.0 driver leaves the asynchronous scheduler component continuously running. This problem causes continuous instances of memory access that prevent the computer from entering the deeper Advanced Configuration and Power Interface (ACPI) processor idle sleep states. These processor idle sleep states are also known as C states. For example, these include the C3 and C4 states. These sleep states are designed, in part, to save battery power. If an otherwise idle portable computer cannot enter or maintain the processor idle sleep states, the computer uses its battery power more quickly than you expect.

Ensuite, le bug ne se manifeste pas quand un branche un périphérique USB, mais un périphérique USB2.

[dulrich]

Ce n'est pas qu'un problème de driver... C'est un problème qui vient du couple driver-chipset. Les portables PC ont depuis plusieurs années de l'USB2, mais le problème n'est présent que depuis peu... c'est pas pour rien ! Windows supporte depuis longtemps l'USB2 également.

Je ne serais pas étonné de savoir qu'Apple a exactement le même problème avec ses drivers... qui doivent très probablement faire exactement les mêmes choses que celui de Windows...

[stephane36]

Ce n'est pas qu'un problème de driver... C'est un problème qui vient du couple driver-chipset. Les portables PC ont depuis plusieurs années de l'USB2, mais le problème n'est présent que depuis peu... c'est pas pour rien ! Windows supporte depuis longtemps l'USB2 également.

Je ne serais pas étonné de savoir qu'Apple a exactement le même problème avec ses drivers... qui doivent très probablement faire exactement les mêmes choses que celui de Windows...

Mon avis, également. Reste à savoir si Apple est plus réactif/perfectionniste que MS. Pour l'instant, quant aux constructeurs PC, ils ont annoncé des autonomies très décevantes sans honte spécialement...

[Ghoun aux os sec...]

Ce n'est pas qu'un problème de driver... C'est un problème qui vient du couple driver-chipset. Les portables PC ont depuis plusieurs années de l'USB2, mais le problème n'est présent que depuis peu... c'est pas pour rien ! Windows supporte depuis longtemps l'USB2 également.

Je ne serais pas étonné de savoir qu'Apple a exactement le même problème avec ses drivers... qui doivent très probablement faire exactement les mêmes choses que celui de Windows...

C'est un problème de driver... apparament codé avec les pieds
Un driver USB maitre est quelque chose d'assez compliqué (voir même carrément ignoble).
Mes connaissaces en USB (1, pas 2) sont assez vielles, mais il y a en gros un tas de machines d'états dont le but est de gérer le réseau, l'ajout / retrait de nouveaus composants devices, etc...

Lorsque la machine fonctionne et communique sur l'USB, ce driverérifier est largement occupé. Lorsque la machine est en veille, normalement, plus rien ne passe par l'USB, donc ce driver devrait être au repos.

Pour communiquer avec un périphérique, le logiciel a 2 solutions (je simplifie) :
- La gestion par interruptions : le chip de gestion USB informe le processeur via une ligne physique que des données sont prêtes à être traitées. Si le proc est en mode veuille, il repart et lance le bout de code associé. Avantage : c'est très propre, rapide, et consomme peut de ressources. Inconvénient : C'est parfois galère à coder, surtout avec windows et sa gestion déplorable du matèriel.

- Le polling : en gros on a une boucle soft qui tourne dans le vide et va lire des registres régulièrement, pour voir si par hasard on aurai pas besoin de lui : Avantage : C'est facile à coder. inconvénient : Ca consomme des ressources inutilement (mais bon, c'est windows...) et manque de bol, pour un portable, l'execution continue de code l'empeche de se mettre en veille.

C'est probablement ce qui se passe avec leur driver. En gros en mode veille, le processeur passe son temps à faire la séquence suivante :

"J'ai quelque chose à faire ?"
"A bin non, je reviendrais dans 10 ms"
"Toujours rien à faire ?"
"A bin non, je reviendrais dans 10 ms"

Du coup, pas de mode veille.

A moins que les ingés qui ont conçus le chipset USB2.0 soient vraiments des glands, le mode polling n'est absolument pas nécessaire. De plus, les ressources hardwares sont en général beaucoup mieux gérés sous un Unix que sous windows.

Il n'y a donc pas de raison pour que ce bug sous reproduise chez Apple, ou alors c'est qu'ils sont masochistes .

[jackjeff]

Après avoir lu l'article il semble très difficile de savoir qui du chipset ou du driver est à mettre en cause, mais si je devais parier, je dirais que le bug serait plus du côté de l'OS. Vu qu'avec la vieille version de Windows çà marche et par expérience avec Microsoft

Explications

Apparemment le bug apparaît uniquement sur une version Windows XP SP 2 (et pas une version antérieure), pour un périph USB 2. Cela vient du fait que Windows initialise une sorte de driver par défaut pour tout périphérique branché. Ce driver lance apparemment un "scheduler asynchrone" dont la fonction m'apparaît un peu comme mystérieuse.

Le fait que tout se passe bien qu'en on a pas un Pentium M ou Core Duo, vient peut-être du simple fait que ces systèmes là n'étaient de toute manière pas capable de passer aussi rapidement et aussi souvent dans les modes d'économies d'énergie... donc en bref, faire tourner ce scheduleur en plus ou pas, n'affectant pas grosso modo la charge globale du proc et donc n'influait pas sur la conso.... Mais le Pentium M et Yonah étant plus futé, ils peuvent se mettre en veille plus souvent... et faire tourner un truc qui accès à la mémoire de manière régulière çà se voit. D'ailleurs on sait pas s'il s'agit de la mémoire RAM de l'ordi (au quel cas c'est du pur soft le pb) ou à celle du périph USB 2 en question (au quel cas le chipset est peut être à mettre en cause... cela dit, pourquoi accéder de manière régulière en lecture à un registre d'un périph USB2 que l'utilisateur n'utilise pas dans certains cas... mmm... bizarre )

Ce scheduler est un truc est assez bizarre et son exacte fonction (peut-être par ailleurs documenté mais je préfère voir si les macbook pro ont ce pb avant de regarder cette doc) reste un peu flou pour moi. D'abord, a quoi çà sert de lancer ce truc, même pour un périphérique que l'utilisateur ne veut pas gérer (car désactivé ou absence de driver...). Ensuite, d'après les dire de Microsoft ce scheduler cherche à accéder de manière périodique à la mémoire. mmm.. Ca ressemble un peu à du polling çà. Le bus USB n'est-il pas capable de générer une interruption pour ses événements asynchrones, plutôt que d'avoir à faire du polling? Bizarre.

Le fix qui consiste à rajouter une clé avec "EnIdleEndpointSupport" à "true" dans la base de registre. Dire que le périphérique est Idle? Apparemment çà suffit à désactiver le scheduler... et ce qui est surprenant est que çà ne nuise pas au comportement de l'ordi ni du périphérique. mmm... Encore plus bizarre. Il sert à quoi alors ce scheduler, si quand on l'enlève çà marche encore?

Le problème du fix est que lors d'un réveil de mise en veille, la clé de la base de registre semble être ignoré et il faut rebooter.. bof. Cà par contre, c'est purement soft. (Bon en même temps, le dit FIX, ressemble plus à un Hack dégueulasse, qu'une vrai solution... )

De deux choses l'une. Soit ce nouveau comportement de la SP2 est en conformité avec la norme USB2 et l'ancienne version de Windows ne la respectait pas à ce sujet là (mais comme tout périph USB se doit de marcher avec Windows, c'était plus le pb des constructeur que de Microsoft...). Soit le contraire, et Microsoft a nettoyé son code de gestion des périphs USB 2 pour se mettre en conformité. Soit un peu des deux, genre ils ont ajouté des fonctionnalités USB2 qui auraient du être prise en charge mais la manière dont çà a été fait (polling?) est crade.

Tout çà pour dire, que je doute FORTEMENT qu'Apple ait le même souci que Microsoft. D'abord, des spécifications techniques identiques pour une même norme amène toujours a des implémentations différentes. (Déjà le cas entre Windows SP1 et SP2. Les codeurs du noyau Linux vous diront qu'ils ont du saloper deux ou trois trucs de gestion de l'USB pour faire fonctionner des clé USB qui marchaient avec Windows mais qui ne respectaient pas la norme tip top à 100%....). Donc qu'Apple ait le même problème avec un scheduleur truc machin dans son code, sachant que la gestion de l'USB à ce niveau la se trouve au niveau de Darwin qui est micro Noyau Mach et des services autour et une surcouche BSD bref.. un gros bordel, mais qui doit être à des années lumières du noyau Microsoft en terme de similarité. Bref.. même problème j'y crois pas....

Par contre qu'Apple ait d'autres problèmes avec le code du noyau de Mac OS X (Darwin) quant à la gestion de l'ACPI et n'arrive pas à tirer partie au maximum des fonctionnalités offertes en terme d'économie d'énergie par ces nouveaux processeurs (beaucoup plus que les vieux G4 mobiles), et qu'il y ait un tas de saloperies dans le noyaux qui tournent pour rien et qui font des accès aux périphs pour rien etc... et que çà finisse par faire surconsommer quand la machine ne fait rien... de çà je ne serais pas surpris. Et je serais pas du tout surpris qu'à l'occasion du lancement du MacBook Pro, ont ait droit à une mise à jour de MacOS X qui patchent le noyau et les drivers USB, USB2, Firewire, Vidéo etc... Et je ne serais pas surprise qu'à l'issu d'une autre mise à jour ultérieure, le MacBook gagne en autonomie.

Le code source de la gestion de l'USB2 est disponible online (Darwin). Un brave et courageux guerrier peut regarder le code et nous dire si oui ou non Apple a du souci à se faire à ce sujet la, ou si le code USB 2 est clean super clean.

[markov]

Question bete pourquoi personne ne teste avec un autre systeme d'exploitation ? (linux me semble t-il gere bien la mise en veille)

L'idée est bonne, mais malheureusement Linux ne gère pas si bien que ça l'ACPI et la mise en veille. C'est très aléatoire, d'une version à l'autre du noyau, d'un chipset à l'autre...

Il serait donc difficile de conclure sur un test avec Linux.

Je viens de parler avec des types du noyau d'apres ce qu'il en resort, c'est que le support de l'ACPI est parfaitement operationnel dans le noyau linux. Dc le test sous linux serait interessant. De plus les problemes viendrait probablement d'un couple bios ACPI buggé. Les developpeurs linux ceux sont apercu qu'enormement d'implementation ACPI (chipset et ce qu'il y a dans le bios) etaient buggees et ne repondez pas a la norme...Enfin bonne nouvelle il semblerait que les chipset intel soit exempt de bug seul certain bios le sont (dc une combinaison mauvais bios bon chipset et hop ca bug). Dc il y a de forte chance pour que les macbookpro n'est jamais souffert de ca car il a un EFI tres probablement developpe avec l'aide d'intel et dc probablement non bugge sur ce point la...

Ce rajoutant a ces bugs, la gestion de l'USB dans windows est peut etre effectivement mal pense, enfin bon, là, on s'en doute, les types du noyau (pas tous) on tendance a cracher sur le code de windows sans le connaitre...Voila pour ma part je pense plutot que le retard des MacBookPro est du a la diffculte d'approvisionement en procs plutot qu'a une bug sur l'USB...

[jackjeff]

"Ghoun aux os secs" a envoyé son message avant que j'ai eu le temps de finir le mien..

Mais pour résumer je soupçonne très fortement Microsoft d'avoir fait un truc dégueulasse dans ce gout la. Je reste quand même perplexe:
- qu'est-ce qui a justifié l'ajout de ce scheduleur dans Windows SP2 alors que la SP1 n'en avait pas besoin. Pour quoi faire exactement?
- pourquoi ce truc est utilisé et tourne même quand le périphérique USB2 ne l'est pas (pas de driver, désactivé par l'utilisateur mmm...)
- pourquoi tout continue à fonctionner correctement quand on désactive le scheduleur. Il sert à rien????

C'est très louche. Et même si l'USB 2 est loin d'être une norme parfaite, je doute qu'elle soit moisie à ce point pour justifier du polling. Mais bon.. on sait jamais... et on ne saura pas tant qu'on ne saura pas ce que fait le dit scheduleur en question (et comme le source de windows n'est pas public... )

Donc très probablement Apple n'aura pas les mêmes problèmes, MAIS ils vont en avoir d'autres. Après tout, c'est la première fois que MacOS X tournera sur du matos qui est capable d'économiser aussi bien l'énergie, et je serai pas étonné que deux ou trois trucs (pas du tout lié à l'USB 2) aient besoin d'un petit lifting pour en profiter... reste à savoir si le jeu en vaut la chandelle..

D'un autre côté, ils ont la vie plus facile que Microsoft, car ils doivent faire fonctionner l'OS que sur un nb réduits de bestioles (=Macs).

Quant à Linux, le jour où on me montre un portable où toutes (sans exception aucune!) les fonctionalités liés à l'économie d'énergie .. bravo! C'est comme le système d'affichage (XOrg commence juste à ne plus être ridicule face à Quartz....), tout çà arrivera un jour mais avec quelques années de retard par rapport au reste.

Nous serons très vite fixés à ce sujet là..... Moi je parie sur aucune pb USB2-conso dans les Macbooks Pro.

[jackjeff]

De plus les problèmes viendraient probablement d'un couple bios ACPI buggé. Les developpeurs linux se sont aperçus qu'enormement d'implémentation ACPI (chipset et ce qu'il y a dans le bios) étaient buggées et ne repondaient pas a la norme...

Cà ne m'étonne pas.. C'est un peu comme au début de l'USB sous Linux. Par exemple certaines clés USB ne fonctionnaient pas avec le noyau parce qu'elles ne respectaient pas la norme. Mais (quasi) tous les constructeurs du monde s'en fichent... pour eux la norme, c'est que cela fonctionne avec Windows. Bref, tout à fini par fonctionner le jour ou les modifications "crades" ont été apporté au noyau. C'était il n'y a pas si longtemps que çà, alors que l'USB fonctionnait depuis longtemps sur Mac et Windows.

Cela a aussi un effet pervers pour les développeurs de Microsoft (enfin s'ils en avaient envie, et s'ils avaient le droit ) car ils ne peuvent pas corriger les bugs de l'OS de peur de casser la compatibilité ascendante. Ou alors ils doivent faire gaffe... (mode troll: donc le résultat, une mise à jour tous les 5 ans!!!) On a vu çà lors du passage à XP, où toute la couche driver a été très nettoyé à karscher... et tous les drivers réécrits.

Apple n'a - en général - pas de souci de ce côté là, car ils ont peu de regret à casser la compatibilité ascendante.

Cela dit, les bugs hardwares, sont légions et en général c'est au soft de s'en accomoder pour les éviter car on peut difficilement modifier le hard. C'est vrai pour les processeurs, les périph USB, donc je vois pas pourquoi les BIOS, chipsets et cartes mères devraient échapper à la règle.

Donc, en pratique sous Linux, arriver à faire fonctionner la mise en veille, l'hibernation, la fréquence variable du proc et la détection de fermeture du capot... tout çà avec ou pas des périph branchés.. çà reste TRÈS difficile pour le commun des mortels, sans avoir à essayer différentes version du noyau et patches et faire gaffe à avoir du matos pas trop exotique ni buggué.. donc bref. çà "marche pas" au sens ou le commun des mortels l'entendent.

Cela dit, à force de gallérer, les developpeurs du kernel vont finir par supporter ce matos buggué (ou une grande partie) et le hardware aura également corrigé les plus gros problèmes... donc çà marchera un jour. On peut pas vraiment leur en vouloir non plus car ils font çà bénévolement et sans support des contructeurs en général.

Perso j'ai jamais réussi à faire tourner 100% des fonctionalités d'économie d'énergie sous Linux (et j'ai pourtant essayé de nombreuses fois et sur du matos différent..) donc j'ai laissé tomber. Et je connais de nombreux gurus Linux qui sont dans le même cas.

[dulrich]

Lorsque la machine fonctionne et communique sur l'USB, ce driverérifier est largement occupé. Lorsque la machine est en veille, normalement, plus rien ne passe par l'USB, donc ce driver devrait être au repos.

Pour être plus précis, l'USB ne supporte pas les interruptions... donc le polling (via l'hôte) est obligatoire. Quand un périphérique USB demande une interruption, il devra attendre que l'hôte l'interroge. Normalement ce polling devrait se faire au niveau du chipset et non au niveau software (est-ce ici le problème?).

Maintenant je sais aussi qu'il y a au moins deux modes de transmission de paquets, l'asynchrones et l'isochrone. Ce dernier permet de gérer les périphériques "temps réel" en effectuant des transactions régulières. Le premier est plus commun (clavier, souris) et ne nécessite qu'un polling "irrégulier".

De plus, les ressources hardwares sont en général beaucoup mieux gérés sous un Unix que sous windows.

Désolé, mais j'ai jamais vu les sources de Windows

Ce message a été modifié par dulrich - 14 Feb 2006, 18:56.

[PO_]

je voudrais poser une question toute naïve :

Ce bug concerne des périphériques USB2, donc haute vitesse, OK ?

Donc, s'il ne se manifeste pas en l'absence d'un périph USB2, en quoi, est-il réellement génant en ce qui concerne une utilisation nomade d'un portable ?

C'est dans ce type d'utilisation que l'on a besoin d'autonomie, et dans ce cas, on ne branche rien dessus. A la limite une souris, mais dans ce cas, ce n'est pas un périph USB2 ?

C'est peut-être une question à la con, mais je me la pose quand même ....

Ce message a été modifié par PO_ - 14 Feb 2006, 20:04.

[g4hd]

Je me dis que ce n'est pas une question idiote, puisque je me la posais exactement ainsi !

[PO_]

Bon ben si 2 macbidouilleurs d'or se la posent, ce ne peut-être qu'une excellente question

[Ghoun aux os sec...]

Lorsque la machine fonctionne et communique sur l'USB, ce driverérifier est largement occupé. Lorsque la machine est en veille, normalement, plus rien ne passe par l'USB, donc ce driver devrait être au repos.

Pour être plus précis, l'USB ne supporte pas les interruptions... donc le polling (via l'hôte) est obligatoire. Quand un périphérique USB demande une interruption, il devra attendre que l'hôte l'interroge. Normalement ce polling devrait se faire au niveau du chipset et non au niveau software (est-ce ici le problème?).

Maintenant je sais aussi qu'il y a au moins deux modes de transmission de paquets, l'asynchrones et l'isochrone. Ce dernier permet de gérer les périphériques "temps réel" en effectuant des transactions régulières. Le premier est plus commun (clavier, souris) et ne nécessite qu'un polling "irrégulier".

De plus, les ressources hardwares sont en général beaucoup mieux gérés sous un Unix que sous windows.

Désolé, mais j'ai jamais vu les sources de Windows

Désolé, je n'rrive pas à quoter par partie

Pour les interruptions : Les ITs générés pour la gestion d'une ressource matèrielle n'ont pas grand chose à voir avec la ressource en question, mais avec :
- Le chipset qui gère ce bus (en général tous sont très bien faits)
- Le logiciel.

Pour mémoire, j'ai vu des interfaces Ethernet (un peu exotiques, certes) tourner... en polling, parce que le gars qui avait routé la carte vait oublié le fil qui allait bien Je vous laisse deviner les performances hallucinates que ça donne.


Pour les drivers : Il suffit de voir le bordel que c'est pour en coder un sous windows et la simplicité sous Linux. J'ai jeté vaguement un oeuil pour Darwin, ça a l'air assez structuré.

[dulrich]

Pour les interruptions : Les ITs générés pour la gestion d'une ressource matèrielle n'ont pas grand chose à voir avec la ressource en question, mais avec :
- Le chipset qui gère ce bus (en général tous sont très bien faits)
- Le logiciel.

Oui mais c'est bien ce dont on parle ... Le problème pourrait justement se trouver au niveau du chipset qui, même en veille profonde (mais pas veille sur disque) le chipset doit faire du polling pour checker les interruptions de l'USB pour un éventuel réveil.
Sinon oui, le type d'interruption dépend du type de bus et par conséquent bien évidemment du chipset qui en contrôle une partie.
Si on prend à l'extrême inverse, il me semble que le contrôle de parité mémoire peut générer des interruptions (non masquables, bon ça c'est une chose) qu'on peut qualifier de ferme et non négociable, sur lesquelles il n'y a bien entendu pas de réel polling. Il en va de même pour les bus ata et scsi (à part qu'eux sont masquables).

Pour en revenir au sujet, il y a eu un semblant de dispute entre Microsoft et Intel sur le sujet... il est fort probable qu'aucun des deux ne soit tout blanc dans cet affaire .

Pour les drivers Windows, j'en conviens, c'est pas forcément la joie... mais faut dire qu'il y a aussi de bonnes idées, sur les .inf par exemple (ça permet même de les faire tourner sur Linux ).

[Ghoun aux os sec...]

Pour les interruptions : Les ITs générés pour la gestion d'une ressource matèrielle n'ont pas grand chose à voir avec la ressource en question, mais avec :
- Le chipset qui gère ce bus (en général tous sont très bien faits)
- Le logiciel.

Oui mais c'est bien ce dont on parle ... Le problème pourrait justement se trouver au niveau du chipset qui, même en veille profonde (mais pas veille sur disque) le chipset doit faire du polling pour checker les interruptions de l'USB pour un éventuel réveil.
Sinon oui, le type d'interruption dépend du type de bus et par conséquent bien évidemment du chipset qui en contrôle une partie.
Si on prend à l'extrême inverse, il me semble que le contrôle de parité mémoire peut générer des interruptions (non masquables, bon ça c'est une chose) qu'on peut qualifier de ferme et non négociable, sur lesquelles il n'y a bien entendu pas de réel polling. Il en va de même pour les bus ata et scsi (à part qu'eux sont masquables).

Pour en revenir au sujet, il y a eu un semblant de dispute entre Microsoft et Intel sur le sujet... il est fort probable qu'aucun des deux ne soit tout blanc dans cet affaire .

Pour les drivers Windows, j'en conviens, c'est pas forcément la joie... mais faut dire qu'il y a aussi de bonnes idées, sur les .inf par exemple (ça permet même de les faire tourner sur Linux ).

heu...

Le chipset c'est du hardware.
Le polling c'est une routine soft qui s'exécute en boucle pour lire des infos pèriodiquement, ça n'a rien à voir.
Qu'un ressource hardware soit capable de communiquer avec son environnement n'empêche pas le proc d'être en sommeil : C'est ce qui se passe par exemple avec une carte Ethernet sortant une bécan de sa veille lorsqu'il y a du traffic.

Il n'y a pas de "type d'interuption". Il y a simplement du hard qui réveille un processeur lorsqu'une action soft est nécessaire pour traiter des données. (bon, c'est vrai qu'après on peut pinailler sur les priorités respectives, mais ça dépend du chipset, du proc, et je ne suis pas au top sur pentium).

Pour en revenir à nous moutons, si le problème était vraiment d'origine hardware... Il ne se produirait pas qu'avec SP2 . Mis bon pour les softeux c'est toujours la faute du hardware, et vice versa.

Sinon, j'ignorais que les NMI existaient encore chez Intel. C'est sympa ce coté "musée des vieux concepts qu'on garde parcequ'on a l'habitude", mais c'est un peu la plaie.

[gertrude]

Donc, en pratique sous Linux, arriver à faire fonctionner la mise en veille, l'hibernation, la fréquence variable du proc et la détection de fermeture du capot... tout çà avec ou pas des périph branchés.. çà reste TRÈS difficile pour le commun des mortels, sans avoir à essayer différentes version du noyau et patches et faire gaffe à avoir du matos pas trop exotique ni buggué.. donc bref. çà "marche pas" au sens ou le commun des mortels l'entendent.

Euh, quand meme. Ca fait un bail que ca marche pour la plupart des bécanes que tu peux trouver, avec Ubuntu ou Mandriva par exemple sans patch ni noyeau spécifique. En tout cas, ca fonctionne parfaitement sans aucune bidouille ici, et je n'ai pas constaté de perte d'autonomie en mettant mon centrino en veille avec un périphérique usb2 de branché. Cela étant dit, il me semble que ces derniers sont completement coupés, les modules correspondants déchargés, avant de rentrer en veille pour éviter d'autres problemes. (et remis ensuite bien sur).

Sinon, pour revenir 2 secondes sur les BIOS buggés: c'est généralement la DSDT qui est incorrecte, parceque les pilotes du contructeur ou de microsoft s'en accomodent ou font des bidouilles par dessus, ce qui n'est pas le cas sous linux, ou l'implementation est proche des specs d'intel. Pas sur qu'on soit épargnés avec les macbook pro, wait and see, la tendance générale dans le monde du PC est à l'amélioration de ce coté, on a meme vu des constructeurs comme Asus fournir des BIOS corrigés apres plainte de certains de leurs utilisateurs.