[3.17.x] freeze aléatoire au boot ( contourné matériellement )

Reconnaissance et configuration du matériel / kernel linux
Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

[3.17.x] freeze aléatoire au boot ( contourné matériellement )

Message par Elbarto » dim. 02 nov. 2014, 21:45

Bonjour,

je constate un freeze aléatoire au boot avec le kernel 3.17.1-1 et 3.17.2-1, ce freeze apparait dès la première seconde du boot ( ou parfois quelques secondes après que systemd se lance, par exemple après la mention "mount /home" )

voici ce que je vois lorsque ça freeze :

Code : Tout sélectionner

:: running early hook [udev]
:: running hook [udev]
:: Triggering uvents...
ça semble se produire tous les 5 à 10 boots environ,

j'utilise le paquet intel-ucode, je me demande si ce ne serait pas un bug lié à la nouvelle méthode de chargement du paquet intel-ucode ? :

https://archlinux.fr/news/changements-d ... code-intel

quelque chose qui genère une "collision", un problème de timing lors du chargement du kernel ?

ma configuration :

archlinux 64 bits
cpu pentium dual core E6800 3.33 Ghz
ati radeon HD4650 PCIe ( radeon open source driver, KMS early start )

dans /etc/mkinitcpio.conf j'ai activé le mode "KMS early start" avec cette ligne :

Code : Tout sélectionner

MODULES="radeon"
c'est un bug vraiment aléatoire, il peut se passer 8 boots sans le moindre freeze au boot, et le bug est apparu à partir du kernel 3.17.1,

est-ce que je suis le seul à être dans ce cas ?

j'ai ouvert un rapport de bug ici :

https://bugzilla.kernel.org/show_bug.cgi?id=87581
Dernière modification par Elbarto le mer. 19 nov. 2014, 20:57, modifié 5 fois.

benjarobin
Maître du Kyudo
Messages : 15903
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [3.17.x] freeze aléatoire dès les premières secondes du

Message par benjarobin » dim. 02 nov. 2014, 21:54

Si tu soupçonnes intel-ucode, pourquoi ne pas le supprimer temporairement ?
Pourquoi mettre dans le rapport de bug la sortie de dmesg d'un démarrage OK ?
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire dès les premières secondes du

Message par Elbarto » dim. 02 nov. 2014, 21:57

parce que je ne sais pas comment récupérer le dmesg quand le freeze apparait, car le bug apparait très tôt dans la procédure de boot, ce qui fait le dmesg n'a probablement pas le temps d'être crée,

je vais désactiver "intel-ucode" pour voir si le bug disparait

benjarobin
Maître du Kyudo
Messages : 15903
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [3.17.x] freeze aléatoire dès les premières secondes du

Message par benjarobin » dim. 02 nov. 2014, 22:01

Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire dès les premières secondes du

Message par Elbarto » dim. 02 nov. 2014, 22:06

tu peux expliciter ton lien ?

je dois faire quoi exactement ?

je dois ajouter "verbose" dans la ligne GRUB_CMDLINE_LINUX_DEFAULT="radeon.dpm=1" de /etc/default/grub ?

benjarobin
Maître du Kyudo
Messages : 15903
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [3.17.x] freeze aléatoire dès les premières secondes du

Message par benjarobin » dim. 02 nov. 2014, 22:12

Le but est d'afficher les informations directement sur le tty.
Par exemple tu commences via "Light Debug", puis si les informations fournis sont insuffisante, tu passes à l'étape au dessus.
Mais je penses que passer directement à "Extreme Debug" est une bonne chose.

Ne t'embête pas à éditer /etc/default/grub. Modifie directement grub.cfg. De toute façon c'est temporaire...

Essaye de reproduire le problème, puis prend une photo quand c'est figé...
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire dès les premières secondes du

Message par Elbarto » dim. 02 nov. 2014, 22:20

ok ;)

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire dès les premières secondes du

Message par Elbarto » dim. 02 nov. 2014, 23:26

bon finalement le problème ne vient pas de intel-ucode parce que même désactivé j'ai encore le freeze aléatoire,

quand le bug apparait une fois que systemd est chargé là il y a des choses intéressantes, quand ça bloque et que j'attends 120 secondes j'ai un message du kernel "call trace", j'ai pris une photo de l'écran :

https://bugzilla.kernel.org/attachment.cgi?id=156341

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » jeu. 06 nov. 2014, 00:34

suis-je le seul à avoir ce bug ?

car c'est très génant, à chaque fois ça corrompt le journal de systemd car je dois faire un reset quand ça bloque,

j'ai testé le kernel 3.18 et j'ai le même souci, à savoir un blocage au boot qui apparait de manière aléatoire ( tous les 5 à 10 boots ),

je suis en train de réinstaller le noyau 3.16-4 pour voir si le bug disparait, je suis presque sûr que ça vient du kernel 3.17 car c'est depuis cette version du noyau que le problème a commencé,

j'ai crée un rapport de bug sur le bugzilla du kernel mais personne ne m'a répondu, c'est très frustrant, c'est la première fois que j'ai un tel problème depuis que j'utilise archlinux ( un an que je suis sous archlinux )

Avatar de l’utilisateur
jaco
Chu Ko Nu
Messages : 344
Inscription : ven. 18 mars 2011, 23:42
Localisation : Toulouse, France

Re: [3.17.x] freeze aléatoire au boot

Message par jaco » jeu. 06 nov. 2014, 00:49

Pas de problème avec 3.17 pour ma part... mais je n'utilise ni module ATI, ni module Nvidia ou assimilé. Essaie de voir de ce côté là ?
Au pire, tu as toujours le noyau LTS (c'est lui que j'utilisais du temps du 3.16 qui faisait freezer lorsqu'on accédait à une partition NTFS)

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » jeu. 06 nov. 2014, 01:01

j'utilise le pilote libre radeon pour ma carte graphique ati radeon hd4650,

à noter que par rapport au pilote NTFS les développeurs ont corrigé justement ce problème dans le noyau 3.17, si ça se trouve la correction du problème a apporté de nouveaux bugs, car j'ai beaucoup de partitions NTFS en plus de ma partition EXT-4, peut-être qu'au boot lorsque le kernel accede aux partitions NTFS ( pour les lister ) le driver NTFS fait planter tout le système, d'où le freeze

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » jeu. 06 nov. 2014, 03:13

je viens d'installer le noyau 3.16.4 et après de nombreux reboots le bug ne s'est jamais produit,

donc le fautif est très certainement le noyau 3.17.x, les développeurs ont dû mettre quelque chose qui gène terriblement le boot sur mon PC,

ça ressemble à un problème de timing ou de synchronisation entre processus, une "collision", 2 processus qui veulent acceder en même temps à une ressource, comme cela n'est pas possible ça crée alors une situation de blocage qui donne l'impression d'un freeze, le disque dur qui n'est plus accessible et qui empêche systemd de continuer le boot, c'est mon hypothèse,

sur des CPU lents comme le mien ( un pentium dual core E6800 3.33 Ghz ) le bug se produit facilement, et peut-être que sur des CPU récents le bug ne se produit pas car la collision n'a pas le temps de se produire ?

bref je suis coincé, il faudrait qu'il y ait d'autres utilisateurs touchés par le bug pour que les développeurs du noyau commencent à s’intéresser à ce bug,

ou bien que je trouve moi même le commit qui a crée ce bug, pas évident car mon PC n'est pas assez rapide pour faire un bissect avec GIT, ça prendrait beaucoup trop de temps, surtout sur un bug qui est aléatoire ( ça se produit tous les 5 à 10 boots ),

il faudrait que j'inspecte le changelog du noyau 3.17.0 afin de cibler les commits suspects

ma configuration :

archlinux 64 bits
cpu pentium dual core E6800 3.33 Ghz
carte mère gigabyte GA-P31-DSL3 ( chipset intel P31 )
ati radeon HD4650 PCIe ( radeon open source driver )
3 disques SATA branchés sur la carte mère
1 graveur DVD SATA branché sur la carte mère
1 disque IDE branché sur la carte mère
1 disque IDE branché sur une carte PCie contrôleur SATA/IDE JMicron JMB363/368

s'il y a des Sherlock Holmes ici qui auraient une piste, un exemple de bug du passé ressemblant à mon cas ( ce serait alors un bug de regression ) je serai preneur :chinois:

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » jeu. 06 nov. 2014, 07:51

quand le freeze apparait au boot je peux lire parfois ce message d'erreur qui donne l'impression que les disques sont mal initialisés avec le kernel 3.17 et 3.18 :

Code : Tout sélectionner

:: running hook [udev]
:: Triggering uevents...

worker [53] /devices/pci0000:00/0000:00:1f.2/ata8/host7/target7:0:1/7:0:1:0 is taking a long time
worker [60] /devices/pci0000:00/0000:00:1f.2/ata7/host6/target6:0:0/6:0:0:0/block/sr0 is taking a long time
https://bugzilla.kernel.org/attachment.cgi?id=156871

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » jeu. 06 nov. 2014, 20:48

je ne suis plus tout seul à avoir le bug :mrgreen:

quelqu'un sur le forum anglais d'archlinux a aussi le bug :
I have the same problem with the 3.17.2 and 3.17.1 kernels. About a third of all boots hangs after "Triggering uvents...". Other times the boot process continues a bit longer and then hangs when mounting either a partition from my SSD or an NFS share. Some times the system boots ok, which seems to indicate a race condition somewhere.

Disabling intel-ucode does not help, but reverting back to 3.16.4 solves the problem for me. I have a 64-bit system with Intel i7-2600K and use nouveau with a GeForce 210. I do not load KMS early.
https://bbs.archlinux.org/viewtopic.php ... 9#p1473209

à mon avis ça va monter crescendo au niveau des témoignages lorsque le kernel 3.17 arrivera peu à peu dans les dépôts stables des distributions officielles linux, surtout avec la masse des utilisateurs d'ubuntu,

ça me rappelle le bug des partitions NTFS ( bug "fuse" dans le kernel 3.16.x ) qui n'apparaissait qu'avec l'utilisation de virtualbox et à condition que la machine virtuelle soit sur une partition NTFS, des conditions très restrictives pour que le bug apparaisse,

dans mon cas du freeze aléatoire au boot je pense que c'est la même chose, il faut avoir une configuration matérielle précise ( vieux matos ? disque branché sur une carte contrôleur IDE/SATA ? un certain type de CPU ? bug de GCC sur des instructions CPU ? )

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » sam. 08 nov. 2014, 16:46

est-ce que vous pensez que l'un de 3 commits relatifs aux timers/IRQ pourraient être responsables du freeze au boot ? :

Code : Tout sélectionner

commit 1d3408209d43d2e72b5d8dbfb9b60fece399d75b
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date:   Sat Aug 16 18:47:15 2014 +0200

    x86: Tell irq work about self IPI support
    
    commit 3010279f0fc36f0388872203e63ca49912f648fd upstream.
    
    x86 supports irq work self-IPIs when local apic is available. This is
    partly known on runtime so lets implement arch_irq_work_has_interrupt()
    accordingly.
    
    This should be safely called after setup_arch().
    
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6fd5de08a5337d0d601f6361671813df4f013da9
Author: Frederic Weisbecker <fweisbec@gmail.com>
Date:   Sat Aug 16 18:37:19 2014 +0200

    irq_work: Force raised irq work to run on irq work interrupt
    
    commit 76a33061b9323b7fdb220ae5fa116c10833ec22e upstream.
    
    The nohz full kick, which restarts the tick when any resource depend
    on it, can't be executed anywhere given the operation it does on timers.
    If it is called from the scheduler or timers code, chances are that
    we run into a deadlock.
    
    This is why we run the nohz full kick from an irq work. That way we make
    sure that the kick runs on a virgin context.
    
    However if that's the case when irq work runs in its own dedicated
    self-ipi, things are different for the big bunch of archs that don't
    support the self triggered way. In order to support them, irq works are
    also handled by the timer interrupt as fallback.
    
    Now when irq works run on the timer interrupt, the context isn't blank.
    More precisely, they can run in the context of the hrtimer that runs the
    tick. But the nohz kick cancels and restarts this hrtimer and cancelling
    an hrtimer from itself isn't allowed. This is why we run in an endless
    loop:
    
    	Kernel panic - not syncing: Watchdog detected hard LOCKUP on cpu 2
    	CPU: 2 PID: 7538 Comm: kworker/u8:8 Not tainted 3.16.0+ #34
    	Workqueue: btrfs-endio-write normal_work_helper [btrfs]
    	 ffff880244c06c88 000000001b486fe1 ffff880244c06bf0 ffffffff8a7f1e37
    	 ffffffff8ac52a18 ffff880244c06c78 ffffffff8a7ef928 0000000000000010
    	 ffff880244c06c88 ffff880244c06c20 000000001b486fe1 0000000000000000
    	Call Trace:
    	 <NMI[<ffffffff8a7f1e37>] dump_stack+0x4e/0x7a
    	 [<ffffffff8a7ef928>] panic+0xd4/0x207
    	 [<ffffffff8a1450e8>] watchdog_overflow_callback+0x118/0x120
    	 [<ffffffff8a186b0e>] __perf_event_overflow+0xae/0x350
    	 [<ffffffff8a184f80>] ? perf_event_task_disable+0xa0/0xa0
    	 [<ffffffff8a01a4cf>] ? x86_perf_event_set_period+0xbf/0x150
    	 [<ffffffff8a187934>] perf_event_overflow+0x14/0x20
    	 [<ffffffff8a020386>] intel_pmu_handle_irq+0x206/0x410
    	 [<ffffffff8a01937b>] perf_event_nmi_handler+0x2b/0x50
    	 [<ffffffff8a007b72>] nmi_handle+0xd2/0x390
    	 [<ffffffff8a007aa5>] ? nmi_handle+0x5/0x390
    	 [<ffffffff8a0cb7f8>] ? match_held_lock+0x8/0x1b0
    	 [<ffffffff8a008062>] default_do_nmi+0x72/0x1c0
    	 [<ffffffff8a008268>] do_nmi+0xb8/0x100
    	 [<ffffffff8a7ff66a>] end_repeat_nmi+0x1e/0x2e
    	 [<ffffffff8a0cb7f8>] ? match_held_lock+0x8/0x1b0
    	 [<ffffffff8a0cb7f8>] ? match_held_lock+0x8/0x1b0
    	 [<ffffffff8a0cb7f8>] ? match_held_lock+0x8/0x1b0
    	 <<EOE><IRQ[<ffffffff8a0ccd2f>] lock_acquired+0xaf/0x450
    	 [<ffffffff8a0f74c5>] ? lock_hrtimer_base.isra.20+0x25/0x50
    	 [<ffffffff8a7fc678>] _raw_spin_lock_irqsave+0x78/0x90
    	 [<ffffffff8a0f74c5>] ? lock_hrtimer_base.isra.20+0x25/0x50
    	 [<ffffffff8a0f74c5>] lock_hrtimer_base.isra.20+0x25/0x50
    	 [<ffffffff8a0f7723>] hrtimer_try_to_cancel+0x33/0x1e0
    	 [<ffffffff8a0f78ea>] hrtimer_cancel+0x1a/0x30
    	 [<ffffffff8a109237>] tick_nohz_restart+0x17/0x90
    	 [<ffffffff8a10a213>] __tick_nohz_full_check+0xc3/0x100
    	 [<ffffffff8a10a25e>] nohz_full_kick_work_func+0xe/0x10
    	 [<ffffffff8a17c884>] irq_work_run_list+0x44/0x70
    	 [<ffffffff8a17c8da>] irq_work_run+0x2a/0x50
    	 [<ffffffff8a0f700b>] update_process_times+0x5b/0x70
    	 [<ffffffff8a109005>] tick_sched_handle.isra.21+0x25/0x60
    	 [<ffffffff8a109b81>] tick_sched_timer+0x41/0x60
    	 [<ffffffff8a0f7aa2>] __run_hrtimer+0x72/0x470
    	 [<ffffffff8a109b40>] ? tick_sched_do_timer+0xb0/0xb0
    	 [<ffffffff8a0f8707>] hrtimer_interrupt+0x117/0x270
    	 [<ffffffff8a034357>] local_apic_timer_interrupt+0x37/0x60
    	 [<ffffffff8a80010f>] smp_apic_timer_interrupt+0x3f/0x50
    	 [<ffffffff8a7fe52f>] apic_timer_interrupt+0x6f/0x80
    
    To fix this we force non-lazy irq works to run on irq work self-IPIs
    when available. That ability of the arch to trigger irq work self IPIs
    is available with arch_irq_work_has_interrupt().
    
    Reported-by: Catalin Iacob <iacobcatalin@gmail.com>
    Reported-by: Dave Jones <davej@redhat.com>
    Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b677a767bcb3b9fbb4c7f921e5ba9577f1577049
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Sat Sep 6 15:43:02 2014 +0200

    irq_work: Introduce arch_irq_work_has_interrupt()
    
    commit c5c38ef3d70377dc504a6a3f611a3ec814bc757b upstream.
    
    The nohz full code needs irq work to trigger its own interrupt so that
    the subsystem can work even when the tick is stopped.
    
    Lets introduce arch_irq_work_has_interrupt() that archs can override to
    tell about their support for this ability.
    
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Cc: Ingo Molnar <mingo@kernel.org>
    Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Frederic Weisbecker <fweisbec@gmail.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
https://gitorious.org/opensuse/kernel/c ... ece399d75b

http://gitorious.ti.com/ti-linux-kernel ... 10833ec22e

http://gitorious.ti.com/ti-linux-kernel ... c814bc757b

ce sont les commits les plus suspects du changelog du kernel 3.17.1 :

https://www.kernel.org/pub/linux/kernel ... Log-3.17.1

benjarobin
Maître du Kyudo
Messages : 15903
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [3.17.x] freeze aléatoire au boot

Message par benjarobin » sam. 08 nov. 2014, 22:55

Le mieux dans ton cas est de compiler un kernel sans ces commit.
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » dim. 09 nov. 2014, 01:58

bon j'ai testé sans ces 3 commits, malheureusement le bug est toujours là,

donc je vais continuer la traque du commit responsable de ce bug,

le commit est peut-être dans la branche 3.16.x, car dans archlinux ils sont passés directement du noyau 3.16.4 au noyau 3.17.1, or entretemps il y a eu d'autres version stables du noyau 3.16.x qui ont été publiées :

3.16.5, 3.16.6, 3.16.7, le commit fautif se trouve peut-être dans ces versions

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » dim. 09 nov. 2014, 12:30

bon je suis en train de faire un git bisect entre la version 3.16.7 ( qui n'a pas le bug ) et la version 3.17 ( qui a le bug ), le tout sur le dépôt git "linux-stable", j'espère pouvoir identifier le commit responsable du bug

Elbarto
Elfe
Messages : 671
Inscription : jeu. 22 déc. 2011, 23:15

Re: [3.17.x] freeze aléatoire au boot

Message par Elbarto » lun. 10 nov. 2014, 23:47

j'ai trouvé le commit qui a introduit le bug grâce à un git bisect :

Code : Tout sélectionner

$ git bisect bad
045065d8a300a37218c548e9aa7becd581c6a0e8 is the first bad commit
commit 045065d8a300a37218c548e9aa7becd581c6a0e8
Author: Guenter Roeck <linux@roeck-us.net>
Date:   Sun Aug 10 05:54:25 2014 -0700

    [SCSI] fix qemu boot hang problem
    
    The latest kernel fails to boot qemu arm images when using scsi
    for disk access. Boot gets stuck after the following messages.
    
    brd: module loaded
    sym53c8xx 0000:00:0c.0: enabling device (0100 -> 0103)
    sym0: <895a> rev 0x0 at pci 0000:00:0c.0 irq 93
    sym0: No NVRAM, ID 7, Fast-40, LVD, parity checking
    sym0: SCSI BUS has been reset.
    scsi host0: sym-2.2.3
    
    Bisect points to commit 71e75c97f97a ("scsi: convert device_busy to
    atomic_t"). Code inspection shows the following suspicious change
    in scsi_request_fn.
    
    out_delay:
    -       if (sdev->device_busy == 0 && !scsi_device_blocked(sdev))
    +       if (atomic_read(&sdev->device_busy) && !scsi_device_blocked(sdev))
                blk_delay_queue(q, SCSI_QUEUE_DELAY);
        }
    
    'sdev->device_busy == 0' was replaced with 'atomic_read(&sdev->device_busy)',
    meaning the logic was reversed. Changing this expression to
    '!atomic_read(&sdev->device_busy)' fixes the problem.
    
    Signed-off-by: Guenter Roeck <linux@roeck-us.net>
    Reviewed-by: Hannes Reinecke <hare@suse.de>
    Acked-by: Jens Axboe <axboe@fb.com>
    Signed-off-by: Christoph Hellwig <hch@lst.de>
    Fixes: 71e75c97f97a
    Signed-off-by: James Bottomley <JBottomley@Parallels.com>

:040000 040000 308ba2598b40aade33c390d7e4a97b0132a2131f 73e54c0ef2dd04c52749b7f108d6ff129decc99b M      drivers
je vais essayer de voir si je peux créer un patch qui annule ce patch qui crée le bug

benjarobin
Maître du Kyudo
Messages : 15903
Inscription : sam. 30 mai 2009, 15:48
Localisation : Lyon

Re: [3.17.x] freeze aléatoire au boot

Message par benjarobin » mar. 11 nov. 2014, 00:02

C'est ultra simple avec git. Il suffit de se placer à la révision stable, puis d'annuler le commit :

Code : Tout sélectionner

git checkout v3.17.1
git revert 045065d8a300a37218c548e9aa7becd581c6a0e8
Mais franchement je trouve très étrange que ce soit ce commit le responsable : https://github.com/torvalds/linux/commi ... d581c6a0e8
Zsh | KDE | PC fixe : core i7, carte nvidia | Portable : Asus ul80vt
Titre d'un sujet : [Thème] Sujet (état)

Répondre