A part rapporter le bogue sur les bugzilla redhat et kernel.org, je ne vois pas perso.
VINDICATORs wrote:A part rapporter le bogue sur les bugzilla redhat et kernel.org, je ne vois pas perso.

Pour le rapport de bug c'est fait et bien documenté mais ça n'a pas l'air de bouger du coté des développeurs kernel...

J'ai essayé avec le dernier kernel 4.11.8, même punition et je suis revenu au 4.11.4...

Après il me reste la solution de refourguer sur le Bon Coin cet Asus UX305 "compatible Linux 2015" pour racheter un ordinateur "compatible Linux 2017"...

J'avoue que de voir qu'une telle régression n'est pas corriger rapidement m'agace un peu....
D'après ce que je vois ça bouge quand même.

Après si cela fonctionne bien avec un noyau, reste dessus le temps d'avoir une solution.

Ce n'est pas toujours bon d'aller trop vite, au moins ton bogue est suivi d'après ce que je vois.

Pense quand même à rapporter le bogue aussi sur le bugzilla du noyau directement.
23 jours plus tard
madko wrote:Asus n'a pas non plus fait grand chose pour que ça fonctionne avant, donc normale qu'ils ne se sentent pas concerné. Après dans les bugzilla tu dis que c'est fixé sur d'autres distro ? Ou c'est un autre soucis ?

Il y a deux choses distinctes:

- un bug découvert en juin et reconnu par Intel sur certains processeurs SkyLake Intel qui font que ceux-ci ont un comportement aléatoire sur certaines suites d'instructions quand Hyper Threading est activé, Debian et Ubuntu proposant ou allant proposer un correctif microcode conformément aux recommandations d'Intel: http://www.zdnet.com/article/debian-linux-reveals-intel-skylake-kaby-lake-processors-have-broken-hyper-threading/

Ce correctif peut aussi être aussi inclus dans le BIOS si le constructeur fait la démarche.

- le fait que les portables Asus UX305UA et semble-t-il Asus UX306U, qui fonctionnent parfaitement avec le kernel 4.11.4 et précédents, ne peuvent pas booter sur les kernel 4.11.5 et suivants

Dans le rapport https://bugzilla.redhat.com/show_bug.cgi?id=1463085 et sur http://forums.fedoraforum.org/showthread.php?t=314575 quelqu'un a fait le lien entre ces deux problèmes...


Pour ma part je suis dorénavant plus circonspect sur le lien entre ces deux problèmes...

Voilà ce que ça donne chez moi le problème de boot sur Asus UX305UA:

-- Logs begin at mar. 2017-05-30 22:47:41 CEST, end at mar. 2017-06-20 10:55:53 CEST. --
juin 20 12:47:00 lx-laptop systemd-journald[200]: Runtime journal (/run/log/journal/) is 8.0M, max 394.1M, 386.1M free.
juin 20 12:47:00 lx-laptop kernel: microcode: microcode updated early to revision 0xba, date = 2017-04-09
juin 20 12:47:00 lx-laptop kernel: Linux version 4.11.6-200.fc25.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 6.3.1 20161221 (Red Hat 6.3.1-1) (GCC) ) #1 SMP Mon Jun 19 17:32:21 UTC 2017
juin 20 12:47:00 lx-laptop kernel: Command line: BOOT_IMAGE=/vmlinuz-4.11.6-200.fc25.x86_64 root=UUID=f961a4ee-762f-465a-b5dd-1234567890 ro rhgb quiet LANG=fr_FR.UTF-8 selinux=0

---/---

juin 20 12:47:01 lx-laptop kernel: [drm] Memory usable by graphics device = 4096M
juin 20 12:47:01 lx-laptop kernel: checking generic (c0000000 1d5000) vs hw (c0000000 10000000)
juin 20 12:47:01 lx-laptop kernel: fb: switching to inteldrmfb from EFI VGA
juin 20 12:47:01 lx-laptop kernel: Console: switching to colour dummy device 80x25
juin 20 12:47:01 lx-laptop kernel: [drm] Replacing VGA console driver
juin 20 12:47:01 lx-laptop kernel: [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
juin 20 12:47:01 lx-laptop kernel: [drm] Driver supports precise vblank timestamp query.
juin 20 12:47:01 lx-laptop kernel: [drm] Finished loading DMC firmware i915/skl_dmc_ver1_26.bin (v1.26)
juin 20 12:47:01 lx-laptop kernel: i915 0000:00:02.0: vgaarb: changed VGA decodes: olddecodes=io+mem,decodes=io+mem:owns=io+mem


juin 20 12:47:01 lx-laptop kernel: [drm:drm_calc_timestamping_constants [drm]] *ERROR* crtc 31: Can't calculate constants, dotclock = 0!


juin 20 12:47:01 lx-laptop kernel: [drm] GuC firmware load skipped
juin 20 12:47:01 lx-laptop kernel: [drm] Initialized i915 1.6.0 20170123 for 0000:00:02.0 on minor 0
juin 20 12:47:01 lx-laptop kernel: ACPI: Video Device [GFX0] (multi-head: yes  rom: no  post: no)
juin 20 12:47:01 lx-laptop kernel: acpi device:0f: registered as cooling_device4
juin 20 12:47:01 lx-laptop kernel: input: Video Bus as /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/LNXVIDEO:00/input/input5
juin 20 12:47:01 lx-laptop kernel: [drm] Cannot find any crtc or sizes - going 1024x768
juin 20 12:47:01 lx-laptop kernel: fbcon: inteldrmfb (fb0) is primary device


juin 20 12:47:01 lx-laptop kernel: ------------[ cut here ]------------
juin 20 12:47:01 lx-laptop kernel: WARNING: CPU: 0 PID: 77 at drivers/gpu/drm/i915/intel_pm.c:3749 skl_compute_wm+0xce3/0x1540 [i915]
juin 20 12:47:01 lx-laptop kernel: WARN_ON(!intel_pstate->base.fb)
juin 20 12:47:01 lx-laptop kernel: Modules linked in: i915 i2c_algo_bit drm_kms_helper crc32c_intel drm serio_raw i2c_hid video
juin 20 12:47:01 lx-laptop kernel: CPU: 0 PID: 77 Comm: kworker/u8:1 Not tainted 4.11.6-200.fc25.x86_64 #1
juin 20 12:47:01 lx-laptop kernel: Hardware name: ASUSTeK COMPUTER INC. UX305UA/UX305UA, BIOS UX305UA.201 10/12/2015
juin 20 12:47:01 lx-laptop kernel: Workqueue: events_unbound async_run_entry_fn
juin 20 12:47:01 lx-laptop kernel: Call Trace:
juin 20 12:47:01 lx-laptop kernel:  dump_stack+0x63/0x86
juin 20 12:47:01 lx-laptop kernel:  __warn+0xcb/0xf0
juin 20 12:47:01 lx-laptop kernel:  warn_slowpath_fmt+0x5a/0x80
juin 20 12:47:01 lx-laptop kernel:  skl_compute_wm+0xce3/0x1540 [i915]
juin 20 12:47:01 lx-laptop kernel:  intel_atomic_check+0xa9b/0x1150 [i915]
juin 20 12:47:01 lx-laptop kernel:  ? drm_mode_object_unreference+0x49/0x80 [drm]
juin 20 12:47:01 lx-laptop kernel:  drm_atomic_check_only+0x326/0x5a0 [drm]
juin 20 12:47:01 lx-laptop kernel:  drm_atomic_commit+0x18/0x50 [drm]
juin 20 12:47:01 lx-laptop kernel:  restore_fbdev_mode+0x14e/0x290 [drm_kms_helper]
juin 20 12:47:01 lx-laptop kernel:  drm_fb_helper_restore_fbdev_mode_unlocked+0x34/0x80 [drm_kms_helper]
juin 20 12:47:01 lx-laptop kernel:  drm_fb_helper_set_par+0x2d/0x60 [drm_kms_helper]
juin 20 12:47:01 lx-laptop kernel:  intel_fbdev_set_par+0x18/0x70 [i915]
juin 20 12:47:01 lx-laptop kernel:  fbcon_init+0x579/0x600
juin 20 12:47:01 lx-laptop kernel:  visual_init+0xd6/0x130
juin 20 12:47:01 lx-laptop kernel:  do_bind_con_driver+0x1da/0x3c0
juin 20 12:47:01 lx-laptop kernel:  do_take_over_console+0x115/0x180
juin 20 12:47:01 lx-laptop kernel:  do_fbcon_takeover+0x5c/0xb0
juin 20 12:47:01 lx-laptop kernel:  fbcon_event_notify+0x69d/0x7a0
juin 20 12:47:01 lx-laptop kernel:  notifier_call_chain+0x4a/0x70
juin 20 12:47:01 lx-laptop kernel:  __blocking_notifier_call_chain+0x47/0x60
juin 20 12:47:01 lx-laptop kernel:  blocking_notifier_call_chain+0x16/0x20
juin 20 12:47:01 lx-laptop kernel:  fb_notifier_call_chain+0x1b/0x20
juin 20 12:47:01 lx-laptop kernel:  register_framebuffer+0x216/0x360
juin 20 12:47:01 lx-laptop kernel:  ? vga_switcheroo_client_fb_set+0x5b/0x70
juin 20 12:47:01 lx-laptop kernel:  drm_fb_helper_initial_config+0x243/0x400 [drm_kms_helper]
juin 20 12:47:01 lx-laptop kernel:  ? __switch_to+0x227/0x460
juin 20 12:47:01 lx-laptop kernel:  intel_fbdev_initial_config+0x18/0x30 [i915]
juin 20 12:47:01 lx-laptop kernel:  async_run_entry_fn+0x39/0x170
juin 20 12:47:01 lx-laptop kernel:  process_one_work+0x197/0x450
juin 20 12:47:01 lx-laptop kernel:  worker_thread+0x4e/0x4a0
juin 20 12:47:01 lx-laptop kernel:  kthread+0x109/0x140
juin 20 12:47:01 lx-laptop kernel:  ? process_one_work+0x450/0x450
juin 20 12:47:01 lx-laptop kernel:  ? kthread_park+0x90/0x90
juin 20 12:47:01 lx-laptop kernel:  ret_from_fork+0x2c/0x40
juin 20 12:47:01 lx-laptop kernel: ---[ end trace 87664b35899a4a2a ]---
Comme je le disais sur l'autre sujet, voici la deuxième réponse:

Le fabricant vas s'appuyer sur des "entreprise" qui seront plus stable.

Par exemple si tu leur sort "j'ai une RedHat" là ils arrivent à savoir de quoi tu parle et comme les mises à jour sont plus rare (faut dire que le noyau de fedora est basé sur le développement permanent du noyau linux) et donc plus stable qu'une Fedora. Donc là ils arriveront à avoir du recul et donc seront plus à même de répondre à ton problème.

Pour le noyau il faut sans doute que quelqu'un prennent le point et puisse avoir le temps de le traiter, mais si cela ne touche qu'un modèle sur XXXXXXXX modèles/périphériques, ça risque d'être un peu plus long. Il faudrait sans doute prévoir une "régression" pour ne plus l'avoir le temps de corriger le problème.
Je ne suis absolument pas convaincu du lien entre le bogue des processeurs en cas d'Hyperthreading et ce que tu rencontres. D'autant que le bogue comme la solution n'ont un impact que très limité, car il faut des conditions précises pour le reproduire.

Ton bogue a été signalé, pas mal de gens ont appuyé, quelqu'un devrait s'en occuper (cela peut être long, n'oublie pas qu'on parle d'un sujet complexe où le matériel est nécessaire pour vérifier et tester). N'oublie pas aussi qu'on est en période estivale, beaucoup de développeurs sont en vacances et ne traitent de fait que les sujets prioritaires.

Personnellement, si je m'y connais en noyau, je ne vois rien de probant qui expliquerait le soucis dans ton cas. Et n'ayant pas le matériel je ne peux pas aller plus loin.

Je pense que ton sujet avancerait plus vite si tu parvenais à trouver le commit du noyau responsable du bogue. Pour cela il faudrait utiliser la méthode git-bisect qui implique que tu saches récupérer les sources du noyau, le recompiler avec les options de Fedora (les fichiers configs dans /boot) et tester jusqu'à tomber sur le commit où ça fonctionne et le commit suivant où ça ne fonctionne pas. Avec cette information il y a moyen je pense que ça aille vite.

Je te conseille aussi de tester les noyaux de Fedora Rawhide, (future F27), c'est le noyau de tests mais plus récent, peut être que cela corrigerait ton problème.
Renault wrote:........................................................
Je pense que ton sujet avancerait plus vite si tu parvenais à trouver le commit du noyau responsable du bogue. Pour cela il faudrait utiliser la méthode git-bisect qui implique que tu saches récupérer les sources du noyau, le recompiler avec les options de Fedora (les fichiers configs dans /boot) et tester jusqu'à tomber sur le commit où ça fonctionne et le commit suivant où ça ne fonctionne pas. Avec cette information il y a moyen je pense que ça aille vite.
........................................................
C'est en effet une bonne méthode, je l'avais utilisé il y a quelques années pour un soucis de pilotes de la carte son de mon ancien portable.
J'avais fini par trouver le commit du kernel qui posai problème,le signalant ensuite aux dev du kernel, qui ont corrigé le tir.

Par contre dire que cela va vite, je ne suis pas convaincu, il m'avait fallu presque 3 jours et un nombre important de reconstruction et d'installation de kernel pour y arriver.
3j... pinaise j'aimerai bien que dans ma boite ça aille aussi vite pour juste cocher sur la case "désactivé" d'un compte utilisateur d'un domaine pour le réactiver (ça leurs prend 2 minutes quand il faut le "désactiver"...)... Ou 3 ans juste pour changer la version de MS Office sur des stations de travail, après l'achat des licences...