Moins d'autonomie sous Linux ? La faute des BIOS et de Windows

Je ne comprend pas en quoi Windows est liée à cette histoire : Linux fait des tests de gestion de l'ASPM en se basant sur la bonne foi du BIOS. Si le BIOS répond à côté de la plaque, c'est bien lui le fautif.

Que Windows prenne le parti de ne pas se fonder sur ce que dit le BIOS, c'est leur oignons (qui pour le coup est la façon de faire qui donne de bons résultats, en attendant que les BIOS soient plus coopératifs).

En quoi la façon de faire de Windows avec le BIOS est la source du problème sous Linux ?

Non , sur les standards , et ni MS ni les fabricants ne les respectent.

Si Windows obéissait à la spec, les concepteurs du thinkpad se seraient dépêchés de corriger leur bug de BIOS plutot que de se faire casser leur produits dans les tests sur l'autonomie...

Ce qui serait encore plus grave, et que je n'ose imaginer, c'est que Microsoft ait des infos confidentielles des différents fabriquants sur quel matos supporterait cette feature...

Rynarion > Faire un article avec des infos lu en diagonale + un titre racoleur
Malheureusement, c'est de plus en plus souvent sur Presence-PC en ce moment...

J'aime bien la philosophie des fabricants de BIOS : "Windows n'en fait qu'à sa tête, donc ça ne sert à rien d'implenter correctement les fonctionnalités, et de toute façon qui utilise Linux ???"
Ca me rappelle les problèmes d'ACPI et la manière dont Windows les gère : http://support.microsoft.com/kb/216573

Pour ceux qui, comme moi, on subi des problèmes divers et variés sur le BIOS de leur PC parce que les développeurs ne le valident que sur Windows et avec des spécifications vagues, cela n'est qu'un des nombreux exemples de mauvais développements.

La question n'est pas l'omniprésence de Windows. La question est que les développeurs réalisent leurs BIOS sans se soucier des normes et des règles de base (genre : je définis l'état d'un flag dans tous les cas de figures possibles plutôt que de ne le définir que pour les cas qui m'intéressent). Evidemment, comme les tests ne se font que sous Windows, le fait que cet OS ne fasse des tests que d'une certaine manière ne permet pas de déceler les erreurs de développement dudit BIOS. CQFD...

Donc, messieurs et dames les développeurs de BIOS, retournez à l'école et apprenez d'abord à développer... (je ne me fais pas des copains là, mais bon :-D)

Nuance : le BIOS est mal foutu parce que ça fonctionne avec Windows qui fait mal ses tests : Microsoft devrait tester correctement. mais comme c'est l'OS majoritaire, les connecteurs de BIOS s'en foutent de bien implémenter.

C'est bien directement lié à Windows : si les tests étaient faits correctement, les BIOS devraient coder convenablement. C'est la méthode de Microsoft, mauvaise, qui fausse le jeu.

faut arrêter un peu de se foutre de la gueule du monde: si le bios répond mal, c'est a cause du bios, pas parce que windows s'en fout.
c'est nouveau ça, balancer un troll le mercredi soir!

windows salauds ! linux aura ta peau (dès qu'ils auront franchi la barre des 2% d'utilisateurs)

@Rynarion: c'est la faute à Windows parce que les gars qui écrivent les BIOS se basent sur le comportement de Windows, et non sur les spécifications, pour écrire leur BIOS - et ils le reconnaissent: lorsque une personne qui a été affectée par le bug a écrit à Gigabyte qu'il y avait un problème dans leur implémentation du BIOS sur sa carte mère toute neuve et que cela entraînait un mauvais fonctionnement de Linux (qui avait implémenté ASPM à partir des spécifications), la réponse a été (traduction littérale): "utilisez Windows". Bien entendu, Gigabyte ne fournissait pas l'OS en question, et pour tout utilisateur de Linux, ça veut dire: "allez vous faire f...tre".

A noter que ce n'est pas la première fois: avec ACPI, Microsoft avait sciemment fourni des tables ACPI fausses aux programmeurs de BIOS, pour s'assurer qu'aucun autre OS ne puisse utiliser ACPI correctement - et pendant des années, Linux a dû tricher en se faisant passer pour Windows NT 4 et patcher lesdites tables à la volée.

Ici, le correctif a été similaire: Linux se comporte comme Windows. A noter que ledit comportement a requis de récupérer tous les fichiers .inf des pilotes Windows et de faire une rétro-ingénierie du noyau NT6.1 rapport à son comportement vis-à-vis d'ASPM - parce que ledit comportement n'est, bien entendu, pas documenté. Et ne sera certainement reconnu comme un bug chez Microsoft, sauf peut-être un jour lorsqu'un développeur bloggera et dira "comme l'implémentation d'ASPM chez Untel fabricant était fausse, nous avons dû la mort dans l'âme implémenter ASPM différemment, et comme Machin et Bidule ont ensuite fait pareil (mais on sait pas pourquoi, hein), on n'a jamais pu corriger le tir".

Je ne vois pas non plus ce qui permet de définir une "façon correcte". Utiliser une technologie par défaut, sauf si mention contraire, ne me semble pas plus mauvais que de vérifier si ladite techno fait partie de la liste autorisée (pas toujours à jour - ce qui provient bien de la paresse des concepteurs de BIOS, non ?). D'autre part, on peut difficilement parler de "standard" si personne ne le respecte.

Ça me rappelle certaines vieilles cartes mères où Linux ne reconnaissait pas l'ACPI alors qu'elle était implémentée dans le BIOS (certes avec plus ou moins de bonheur)... C'était la grande époque des chipsets i440xx (notamment ; Pentium II/III/Celeron 1ère génération) où il fallait (et il faut toujours même avec des kernels récents) forcer l'usage de l'ACPI en passant l'argument qui va bien au kernel (acpi=force) ne serait-ce que pour pouvoir éteindre le PC !!

Le fait est que vu que Windows ne fait aucun test à ce niveau, le créateur du BIOS se dit simplement "pourquoi je me casserais la tête à implémenter cette fonction si windows ne le regarde pas".

C'est comme cela qu'on se retrouve avec des applications dont le comportement buggé est un comportement normal.

Ahlala... Le respect des standards et des normes...

je suppose :
Windows ne fais pas l’effort de gerer correctement ce test développeur de bios ne fait pas d'effort de corriger (et qui ne pense que pour windows) => probleme pour linux qui le gere correctement.

Quel troll?

Les messieurs t'expliquent le problème comme suit:
1) il y a une norme pour la gestion de l'énergie dans les BIOS
2) Windows gère ces normes selon son bon vouloir (comprendre par là n'importe comment)
3) les constructeurs, constatant ce problème, adaptent les BIOS pour que Windows ne pose pas de problème (95% du marché... ça compte)
4) Linux, développé dans le respect des normes, se retrouve donc à avoir des soucis d'autonomie, faute de gérer des BIOS non normés
5) Le correctif Linux est JUSTEMENT d'ajouter un comportement "Windows like" sur la gestion de l'énergie.

C'est plus clair comme ça?

J'avoue avoir du mal à comprendre cette attaque gratuite de windows.
La politique de windows est différente de celle de linux, certes mais ce que l'on dit là est donc que linux détient la vérité absolue ?? Puisque l'on dit explicitement que windows procède de manière incorrect ??

Windows possède un certain nombres de défauts, mais est-il vraiment nécessaire de lui mettre en plus sur le dos des problèmes qui ne le regardent en rien ?
Surtout pour dire ensuite que le noyau linux va être patché pour procéder de la même manière ??

Même si il ne détient pas la vérité absolue Linux a le bon gout de respecter les normes...

alq67: faut apprendre à lire, coco.
- Il y a une spécification écrite d'ASPM. Elle a été rédigée par un consortium de fabricants de matériel "haut de gamme" (genre AMD, Intel, HP, Sun/Oracle... Les gars qui font les composants, ou qui fabriquent des machines qui doivent tourner 24/7)
- Linux a implémenté cette spécification écrite comme marqué, et ce de manière stricte.
- Microsoft n'a pas implémenté la spécification dans Windows, et a juste sorti un bricolage qui marche.
- les fabricants de matériel grand public (Gigabyte, Asus etc. qui achètent des BIOS tout faits chez AMI etc. et paient ensuite un Indien ou un Chinois au lance-pierre pour l'adapter au matériel) mettent ASPM dans le BIOS d'une manière qui marche avec Windows, sans même ouvrir la spécification.

Si Microsoft avait implémenté ASPM dans Windows d'après la spécification, Gigabyte etc. auraient été forcés d'implémenter ASPM d'après la spécification aussi - et Linux n'aurait pas déconné et dû réimplémenter ASPM.

Donc, on se retrouve avec une première implémentation sous Linux qui sert à rien, une spécification inutile, et du matos qui dès qu'on le regarde de travers, ou qu'on met à jour/change le SE, déconne - si par exemple, Windows 9 requiert une implémentation d'ASPM strictement conforme à la spécification), il faudra:

- soit mettre à jour le BIOS de toutes les cartes mères (on peut rêver)
- soit changer de matériel (ça plaît bien aux fabricants; moins aux consommateurs)
- et au passage, redévelopper à toute vitesse l'implémentation d'ASPM dans les BIOS 'grand public' (toujours par le Chinois ou l'Indien payé au lance-pierre, sauf que ça fait 2 fois qu'on le paie pour la même chose - et faut répercuter le coût sur le prix du produit).

Qui l'a dans l'os? Le consommateur, encore et toujours, qu'il soit sous Linux ou pas. Les Linuxiens s'en rendent juste compte plus vite.

Ouah! Jamais vu une telle mauvaise foi...
Et les développeurs de Linux ne pouvaient pas faire de tests eux-mêmes, avant de se lancer bille en tête? J'ai du mal à croire qu'avec l'immense communauté Linux, pas un n'ait penser à tester d'autres stratégies de gestion de l'ASPM! Il me semble que l'expérimentation est la base de tout, quand on développe des technologies.
Un peu facile d'incriminer Windows, comme un écran de fumée pour masquer ses propres lacunes. Bel exemple de déni de la part des Linuxiens.

Gnééé?? Le monsieur t'explique qu'il y a une NORME, que les assembleurs/constructeurs sont supposés la RESPECTER... et qu'ils ne le font pas pour coller à une marque et non à la NORME. Et c'est linux qui fait du sale boulot? Pour info, le comportement windows n'est pas normalisé, ce sont les constructeurs qui s'adaptent pour tant bien que mal y coller... et là, on t'explique que linux "simule" des conneries pour que cela fonctionne. Donc OUI, Microsoft fait n'importe quoi, et les constructeurs sont pires encore puisqu'ils se mettent à en faire autant pour coller non pas à un standard, mais à bricolage pourri.

Oui! Il faut coller ça sur le dos de MS. Quand on fournit un produit aussi largement diffusé, on a la politesse de respecter les normes en vigueur, et pas de réinventer la poudre pour emmerder les constructeurs de matériel... et donc, dans la foulée, les OS alternatifs qui se retrouvent face à du matériel fonctionnant non comme la norme, mais comme MS le voudrait.

La norme c'est pas Microsoft ?













Bon, j'ai trouvé la porte......................................................> []

@Ryanarion: C'est le contraire, la plupart de ces bios ont été codés après windows, ils ont testé avec windows et vu que ça marchait comme ça, en violation de la spec, ils n'ont donc pas codé la fonction correctement. La cause est bien la gestion qu'en fait windows.

quelque part (en simplifiant à l'extreme) tout dépend comment on interprete la norme!

windows si réponse != NON alors oui
Linux si réponse != OUI alors non

l'approche de MS me parait un peu dangereuse car pourait éventuellement entrainer des instabilité si le système ne répond rien alors qu'il ne suporte pas cette norme et qu'en plus il se vautre à la réception des ordres liés.

Mais les seuls rééls responsables restent les sociétés d'édition de ces bios qui vont au plus rapide en ne se souciant pas de la norme...

Et pour les énervés des messages précédent, relisez l'article, MS réalise le test ...
puis lisez la norme et là ... c'est le drame!
c'est plein de may, should ...

issu de la spec 2.0:

ASPM Control = 00b
Port must not bring a Link enter L0s state.

en gros: Si le matos ne supporte pas l'ASPM, la connection vers le L0 ne doit pas être réalisé ( côté materiel donc)

issu de l'érata de fevrier 2010
ASPM Control = 00b
Port’s Transmitter must enter L0s state.
en gros: Si le matos ne supporte pas l'ASPM, le soft ne doit pas demandé à l'activé


ils ont quand même en changeant 3 mots complétement inversé la logique du bazar!

Et si vous croyez que ça sera mieux avec EFI, vous pouvez vous fourrer le doigt dans l'œil, parce que les bidouilles commencent.

Non mais l'EFI, c'est partis sur de mauvaises bases, une grosse merde sans nom dicté par des intérêts commerciaux (notamment ceux de MS) et non technique.

Par exemple le fat32 pour la partition EFI, laissez moi rire, bourré de brevet, simpliste (et pas simple), dépassé technologiquement depuis les années 90, etc. Bref en dépit du bon sens.

Gogh le borgne qui accuse les gens normaux de l’absence
Des monocle chez l’opticien du coin.... Wow vive linux
Et vive la bêtise humaine....

Et avec les nouveaux BIOS UEFI, c'est géré de la même façon ou différemment ?

Article d'une logique bizarre.
Je cite : "Le seul moment où la technologie sera désactivée manuellement est quand le BIOS l'indiquera explicitement".
Comment peut-on desactiver une technologie alors que le materiel indique l'absence de cette technologie ? Soit elle y est et je peux la retirer, soit elle n'y est pas et alors il n'y a rien à faire.