Eric a écrit 60 commentaires

Dans le post initial, je pensai que l’acpi device:02 était un port PCI Express.
En fait j’ai maintenant comme un doute à ce sujet.

En fait /sys/bus/acpi/devices/device:02 est un lien vers ../../../devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/device:02
et :

$ ls  -Al /sys/devices/LNXSYSTM\:00/LNXSYBUS\:00/PNP0A08\:00/device\:02/
total 0
-r--r--r--  1 root root 4096 avril 30 17:39 adr
drwxr-xr-x  3 root root    0 avril 30  2020 device:0b
drwxr-xr-x 13 root root    0 avril 30  2020 LNXVIDEO:00
-r--r--r--  1 root root 4096 avril 30 17:39 path
lrwxrwxrwx  1 root root    0 avril 30 17:39 physical_node -> ../../../../pci0000:00/0000:00:01.0
drwxr-xr-x  2 root root    0 avril 30 17:39 power
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D0
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D2
drwxr-xr-x  2 root root    0 avril 30 17:39 power_resources_D3hot
-r--r--r--  1 root root 4096 avril 30 17:39 power_state
-r--r--r--  1 root root 4096 avril 30 17:39 real_power_state
lrwxrwxrwx  1 root root    0 avril 30  2020 subsystem -> ../../../../../bus/acpi
-rw-r--r--  1 root root 4096 avril 30  2020 uevent
drwxr-xr-x  3 root root    0 avril 30  2020 wakeup

Je n’arrive pas à savoir à quel matériel cet acpi device:02 est associé.
J’ai tenté, en vain, divers outils pour le découvrir : acpi, acpitail, hardinfo, lshw, dmidecode, discover , inxi.

Comment faire pour identifier le hardware correspondant ?

J’ai trouvé une autre piste:
En effet, je me suis aperçu qu’avec lightdm je n’avais pas le temps de latence à la connexion contrairement à GDM !
Après lecture des logs, la différence entre les deux c’est que GDM fait un VT switching (changement de terminal virtuel) et pas lightdm.
GDM se lance sur le tty1, et après la connexion il lance la session sur le tty2.
Alors que lightdm se lance sur le tty7 et lance la session sur le même tty7.

Du coup j’ai effectué des tests de VT switching manuel (à coup de Ctrl+Alt+F(1-6)).
Il y a bien un temps de latence la première fois que l’on passe d’un VT graphique à un VT texte (ou l’inverse, selon que le paramètre de boot splash est activé ou non) et des erreurs ACPI à chaque VT switching.

A priori le VT switching c’est de la responsabilité du noyau et de logind (systemd).

Du coup, après de multiple essais, j’ai enlevé la radeon ainsi que le DisplayPort de la i915 (y a pas de DisplayPort sur mon laptop) du seat0 avec une règle udev que voici:

# There is no DiplayPort on this laptop, remove from seats
SUBSYSTEM=="drm", KERNEL=="card0-DP-1", TAG-="seat", TAG-="master-of-seat"

# Remove radeon from seats
SUBSYSTEM=="drm", KERNEL=="card1", TAG-="seat", TAG-="master-of-seat"
SUBSYSTEM=="drm", KERNEL=="renderD129", TAG-="seat", TAG-="master-of-seat"

Et la, je n’ai plus aucun temps de latence avec GDM, mais les erreurs ACPI perdurent au VT Switching…
(J’ai bien vérifié que la radeon continue de s’activer avec un DRI_PRIME=1)

Après de multiples relectures de mes logs, j’ai trouvé le message suivant :

kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query ignored

En utilisant le paramètre de boot acpi_osi=Linux, le message devient :

kernel: ACPI: [Firmware Bug]: BIOS _OSI(Linux) query honored via cmdline

Mais, d’après les logs, ça n’a pas l’air de changer grand-chose.

---

De plus, il y a ces autres messages dans les logs :

  kernel: ACPI: Added _OSI(Module Device)
  kernel: ACPI: Added _OSI(Processor Device)
  kernel: ACPI: Added _OSI(3.0 _SCP Extensions)
  kernel: ACPI: Added _OSI(Processor Aggregator Device)
  kernel: ACPI: Added _OSI(Linux-Dell-Video)
  kernel: ACPI: Added _OSI(Linux-Lenovo-NV-HDMI-Audio)
  kernel: ACPI: Added _OSI(Linux-HPI-Hybrid-Graphics)

J’arrive à les faire disparaître à l’aide de du paramètre de boot acpi_osi=!string
Par exemple, acpi_osi=!Linux-HPI-Hybrid-Graphics acpi_osi=!Linux-Lenovo-NV-HDMI-Audio fait disparaître les 2 dernières lignes.
Mais là non plus, je n’obtiens pas de résultats tangibles

---

Sur le web, je n'ai trouvé aucunes bonnes explications sur ces paramètres acpi_osi=
Si quelqu’un sait comment ça marche, ou a des liens, je suis preneur de ses explications.

En utilisant le paramètre de boot amdgpu.rupm=0, j’arrive aux mêmes résultats.
À condition de blacklister le module radeon, et bien entendu d’activer le support du module amdgpu pour ma carte Radeon — Sun XT / HAINAN, famille Sea Islands (SI).

Si je démarre le PC avec le paramètre « radeon.runpm=0 », les erreurs ACPI disparaissent, ainsi que le temps de latence après la connexion avec gdm3.

Malheureusement cela désactive la gestion dynamique de la carte additionnelle, la radeon restant allumé en permanence:

$ cat /sys/kernel/debug/vgaswitcheroo/switch
0:IGD:+:Pwr:0000:00:02.0
1:DIS: :Pwr:0000:01:00.0

Oui, j’ai bien pensé à un bug du BIOS, d’ailleurs j’ai d’autres messages d’erreur ACPI que je peux faire disparaître en blacklistant le module kernel lpc_ich.
Je l’ai bien mis à jour régulièrement.
Mais HP parle, sur son site web, d’une version F.28 Rev.A, parue le 23/03/2017, mais le ficher téléchargé installe une version F.28, parue le 14/03/2017. Une piste serait de trouver cette version F.28 Rev.A, si elle existe.

Sinon j’ai compilé un noyau avec le debug ACPI et PCI. J’ai bien des messages supplémentaires pour le PCI, mais pour l’ACPI, rien de plus. Je vais donc essayer de trouver les options de boot qui activent les messages de debug de l’ACPI.

Il y a d’autres options de boot pour l’ACPI que je n’ai pas encore tenté comme « acpi_rev_override » car je comprends pas encore très bien ce qu’elle fait.
(si quelqu’un a des liens…)

Sinon je me disais que je pouvais mettre le « power mangement » sur « off » juste pour le port PCI Express incriminé, ça pourrait fonctionner. À essayer aussi.

y a aussi des outils pour savoir ce qui consomme, mais j'ai perdu le nom.

powertop ?

sinon pour changer des valeur dans /sys/bus/acpi tu dois pouvoir le faire avec sysctl*

Certes oui, mais le fichier en question doit contenir l'état du périphérique :
- D0 (actif)
- D1 (état optionnel)
- D2 (état optionnel)
- D3Hot (désactivé)
- D3Cold (complètement désactivé)

Comment savoir quel état écrire ? Et à quels moments écrire cet état ?

Sinon il y a un paramètre de boot kernel, "acpi.power_nocheck" qui est censé faire que le kernel ignore cet état mais il n'est pas documenté sur kernel.org.
Je l'ai déjà essayé, mais ça ne change rien

La page du wikipédia anglais donne plus d'exemples :

Embrace, extend and extinguish

Pour ceux qui aurait la mémoire courte (Atom et VSCode étant des produits Microsoft):
[Embrace, extend and extinguish]

Ils ont tous les trois été testés sous Debian 9 (view the other specifications):
https://h-node.org/notebooks/catalogue/en/1/1/undef/undef/2019/undef/compatibility/undef/undef/undef

D'après h-node.org, tu peux jeter un œil aux Slimbook One, Excalibur et Eclipse:
https://slimbook.es/en

Pourquoi éviter Framasoft ?
En effet, ils font partie de la liste de CHATONS, eux aussi (à Lyon).

Leur solution Framagenda repose sur Nextcloud et son application Agenda.
Ils ont toute une série de guides intéressants:
Thunderbird
GNOME
KDE
Android
IOS
Ubuntu Touch

http://www.omgubuntu.co.uk/2016/04/m10-ubuntu-tablet-user-reviews-video

D après TechAdvisor, non:
http://www.pcadvisor.co.uk/review/smartphones/meizu-pro-5-ubuntu-edition-review-mwc-2016-video-3635719/

Il y bien une revue vidéo:
http://www.omgubuntu.co.uk/2016/04/m10-ubuntu-tablet-user-reviews-video

J'ai l intention de faire une review de la tablette que je choisirai…si j arrive à la faire marcher sous GNU/Linux !

Je vais essayer de regarder ce we pour mon aspire switch 10, mais je suis moyennement optimiste, même si j'ai l'habitude de me retrouver avec des versions de distro en développement (cooker, cauldron désormais, rawhide un peu…).

Tiens nous au courant..

Merci beaucoup, c'est très complet.

En fait je pense à faire un wiki sur le sujet, c'est pour ça que je cherche plus d'info.
En tout cas merci de ton aide.

Au 1/10/2015, le SmarPad 3 est disponible sur l'evi store au prix de 699€ (sans OS).

Tu as eu l'occasion de tester des Acer Iconia W700 ?
Ou tu as des liens ?

J'oubliais, il existe une remix de fedora pour les tablettes BayTrail: Fedlet

Intel Atom Z3735F Quatre Coeurs 1,33 GHz. Visiblement l'OS peut être désormais en 64 bits sur ces modèles (une chance pour que l'UEFI ne soit pas en 32 bits…).

Apparemment les UEFI continuent d'être en 32 bits quelque soit la marque (sauf à priori sur les Cube i7-CM). Pourquoi ?

(Voir aussi mon post plus bas)

d'un autre côté je n'ai pas de machine x86 récentes type BayTrail mais j'ai cru comprendre que le support de Linux était assez aléatoire et son installation sur un EFI 32 bits pas super simple non plus,

D'après les infos que j'ai pu glaner ici et là, les BIOS sur les machines équipées de processeurs Intel Atom BayTrail sont de type UEFI 32 bits. La raison de cela serait que Windows 8, à l'origine, avait un bug qui l'empêchait de prendre en charge des BIOS UEFI 64 bits.
Depuis, ce bug a été corrigé par Microsoft, toutefois les machines équipées de BayTrail continueraient d'être équipées de BIOS UEFI 32 bits (si quelqu'un sait pourquoi, qu'il n'hésite pas poster).

Heureusement, plusieurs distributions Linux utilisent par défaut un kernel qui prends en charge le mixed-mode (par exemple Ubuntu 15.04 ou 14.10).
Toutefois l'image ISO de ces distributions ne contient pas toujours de bootloader 32 bits (comme Ubuntu 15.04 ou 14.10), il faudra alors en trouver et en installer un sur le médium de boot.
Après l'installation de la distribution, il faudra aussi installer un grub 32 bits (Ubuntu 14.10 ne contient pas ne paquet grub 32 bits), pour pouvoir rebooter.

La Cube i7 Remix semble défier toute concurrence à [prix plancher].(http://www.cube-tablet.com/cube-i7-remix-11-6-inch-64-bit-intel-tablet.html)
La question est de savoir si on peut y mettre GNU/Linux sachant que le modéle Cube i7-CM supporte Ubuntu