[Noyau Linux] Version 6 et des brouettes

Recherche :

Mot : Pseudo : Filtrer Aller à la page :
Page : 1 2 3 4 5 .. 171 172 173 .. 179 180 181 182 183 184 Page Suivante Page Précédente Bas de page
Auteur	Sujet : [Noyau Linux] Version 6 et des brouettes

MysterieuseX

Chieuse

Reprise du message précédent :

Ralph- a écrit :

Je ne vois vraiment pas de quel PID1 tu veux parler :whistle:
Et pourquoi ils n'utiliseront pas cap ? Enfin globalement, j'ai quand même l'impression qu'ils veulent corriger le tir avec les cgroups, dont il faut bien une interface minimale pour le suerland si on veut quand même s'en servir non ? Sur ce, à demain !

Ben quand je dit qu'il ne l'utiliseront pas, c'est dans l'immédiat, pas avant que ça soit dev.
Et l'interface ... Tu crois qu'on fait comment ? C'est un /proc, donc ben scripts a la main etc ...

Message cité 1 fois

Publicité

o'gure

Modérateur
Multi grognon de B_L

chercheinfos a écrit :

Salut, c'était juste pour dire que Ernestor est un gros con,

bisous à tous. :hello:

1 post dans cette cat, 1 insulte. Bye

Message édité par o'gure le 09-08-2014 à 12:54:30

---------------
Relax. Take a deep breath !

Ralph-

★ You'll hate me. ★

MysterieuseX a écrit :

Ben quand je dit qu'il ne l'utiliseront pas, c'est dans l'immédiat, pas avant que ça soit dev.
Et l'interface ... Tu crois qu'on fait comment ? C'est un /proc, donc ben scripts a la main etc ...

Je voulais parler de cgset par exemple donc en passant par la lib libcgroup, enfin bon, j'ai pas été très clair sur le coup. C'est clair qu'on peut passer par le FS virtuel, mais ce n'est pas la seule méthode. D'un autre coté, ptete bien que libcgroup est tout pourrie pour ce que tu fais.

Magicpanda

Pushing the envelope

http://kernelnewbies.org/LinuxChanges

Changelog 3.17

---------------
" Quel est le but du capital ? Le but du capital c'est produire pour le capital. L'objectif, lui, est illimité. L'objectif du capital c'est produire pour produire." - Deleuze || André Gorz - Vers la société libérée

Elbarto

j'ai besoin d'aide:

--> avez-vous remarqué un freeze aléatoire au boot avec le kernel 3.17 ?

j'ai ce problème depuis le kernel 3.17 ( bug présent aussi avec le noyau 3.18.x ), tous les 5 à 10 boots le boot s'arrête, soit à cette étape :

:: running early hook [udev]
:: running hook [udev]
:: Triggering uvents...

soit quelques lignes plus bas après le montage d'une partition :

mount JEUX

mount SAUVEGARDE

qui sont des partitions NTFS,

systemd stoppe alors le boot et 5 minutes après il m'affiche ce message d'erreur :

systemd-udevd:236 blocked for more than 120 seconds

et ensuite il est dans l'impossibilité de continuer le boot, il m'affiche plein de messages d'erreurs relatifs encore à systemd-udevd, c'est comme si les disques dur n'étaient plus accessibles ou bloqués par 2 processus qui se disputent la même ressource, une sorte de collision,

en installant le noyau 3.16.4 là je n'ai plus de problèmes tout est Ok,

donc le fautif est clairement le noyau 3.17,

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

j'ai posté un rapport de bug sur le bugzilla du kernel mais je n'ai aucune réponse des développeurs, ça semble n’intéresser personne

Message édité par Elbarto le 06-11-2014 à 03:47:04

MysterieuseX

Chieuse

Aucuns problèmes ici.

make install

C'est peut-être udev qui révèle un bug dans le 3.17. Essaye 3.17 + un ancien udev.

Message édité par make install le 06-11-2014 à 09:34:27

Elbarto

concrètement ça veut dire quoi ?

udev n'était pas censé être integré dans systemd ?

comment avoir un ancien udev ?

j'utilise archlinux

gee

Bon ben hon

Installe une ancienne version de systemd.
Le 216-3 date du 1er septembre, tu peux voir avec un plus vieux.

---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"

make install

udev n'est pas *dans* systemd mais il fait partie du projet systemd et a sûrement quelques dépendances dessus maintenant...
J'avoue que je connais pas le nom du paquet par coeur, mais bon ça se retrouve vite pour downgrader et tester
ls /var/cache/pacman/pkg/$(pacman -Qo udev)*

Publicité

gee

Bon ben hon

Il n'y a pas de paquet udev, c'est dans systemd.

Code :

Name : systemd
Version : 217-5
Description : system and service manager
Architecture : x86_64
URL : http://www.freedesktop.org/wiki/Software/systemd
Licenses : GPL2 LGPL2.1 MIT
Groups : None
Provides : nss-myhostname systemd-tools=217 udev=217

Message édité par gee le 06-11-2014 à 10:44:05

---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"

Elbarto

quelqu'un sur le forum anglais d'archlinux a aussi le bug :

Citation :

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 [...] 9#p1473209

si vous voyez des utilisateurs sur les autres forums des distributions linux ( fedora, ubuntu, debian, gentoo, SuseLinux ) se plaignant de freezes aléatoires au boot avec le kernel 3.17 alors postez le lien ça m’intéresse,

car je cherche l’élément déclencheur du bug, en analysant tous les témoignages on devrait pouvoir réussir à isoler le coupable [:pandaman2]

j'ai même testé la version "linux-next" ( la version la plus récente du noyau linux, encore plus récente que la version "mainline" ) et j'ai encore le bug, c'est la preuve que les développeurs ne sont probablement pas encore au courant du bug ou n'ont pas encore trouvé de solution

http://git.kernel.org/cgit/linux/k [...] x-next.git

idéalement il faudrait que cette affaire se résolve avant le passage en version stable du noyau 3.18

Message édité par Elbarto le 06-11-2014 à 21:24:27

j_c_p

Linux user

Pas de souci ici.

Message cité 1 fois

morris aka the moose

en décompensation maniaque

j_c_p a écrit :

Pas de souci ici.

tu es où?

---------------
"La chance de voir une biche" Archlinux :: http://www.archlinux.org/ ::

j_c_p

Linux user

Près de ma config, pourquoi ?

Elbarto

concernant mes freezes aléatoires au boot du noyau 3.17.1 je suspecte fortement 3 commits d'avoir introduit le bug,

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

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/kern [...] ece399d75b

http://gitorious.ti.com/ti-linux-k [...] 10833ec22e

http://gitorious.ti.com/ti-linux-k [...] c814bc757b

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

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

make install

Checkout le commit juste avant le premier des 3 et teste, non ?

Elbarto

c'est ce que je vais faire quand j'aurais le temps

par chance il n'y a pas eu beaucoup de commits dans le kernel 3.17.1, ça devrait aller vite pour trouver le coupable

Elbarto

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

gee

Bon ben hon

As tu le soucis avec un 3.17?
Il etait offert par arch, du moins en testing.

---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"

Elbarto

je le trouve pas ce 3.17 tout court dans le site d'archlinux :

https://projects.archlinux.org/svnt [...] ages/linux

je suppose qu'il faut prendre directement le code source du 3.17 sur le site du kernel :

https://www.kernel.org/pub/linux/ke [...] .17.tar.gz

Message édité par Elbarto le 09-11-2014 à 05:52:14

gee

Bon ben hon

bah si: https://projects.archlinux.org/svnt [...] e7750e5356

3.17-1 c'est le 3.17

---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"

Elbarto

j'ai testé le 3.17 tout court ( sans le patch lié au 3.17 ) car j'avais pas encore vu ton message, et le bug est encore présent,

ça signifie que le commit se trouve en fait dans la branche 3.16.x, dans l'un de ces 3 noyaux : 3.16.5, 3.16.6 et 3.16.7

je vais donc tester le 3.16.6 en reprenant le pkgbuild du 3.16.4, je changerai juste le numéro ( 6 à la place du 4 ), ça ira chercher le bon code source du 3.16.6,

si le bug n'est pas présent dans le 3.16.6 alors ça signifie qu'il est présent dans le 3.16.7, inversément s'il est présent dans le 3.16.6 alors il faudra tester le 3.16.5, sachant que le bug n'est pas présent dans le 3.16.4

Message édité par Elbarto le 09-11-2014 à 07:59:30

gee

Bon ben hon

N'est-il pas possible que ce bug ne soit pas present dans les 3.16.x mais seulement en 3.17.x ?

---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"

Elbarto

oui c'est une possibilité si les commits backportés dans le 3.16.5, 3.16.6 et 3.16.7 ne contiennent pas le commit coupable du bug

il faudra alors utiliser la fonction "bisect" de git pour trouver le commit coupable en donnant comme plage d’essai le noyau 3.16.7 et le noyau 3.17 tout court ( 3.17-1 ),

qu'en penses-tu ?

Message édité par Elbarto le 09-11-2014 à 08:13:09

gee

Bon ben hon

Je pense que bonne chance
Entre 3.17 et 3.16.4 il doit y avoir pas mal de commits...

Apres je n'ai pas regarde sur git, mais il n'est pas impossible que le 3.16.7
soit sur une autre branche que le 3.17, dans ce cas je ne sais pas si tu pourras faire un bisect entre ces 2 tags.

Enfin, tente le 3.16.7 et tu verras bien.

---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"

make install

Les kernels stable 3.x.y sont un repo complètement différent des 3.x(.0)
Les premiers sont gérés par Greg KH alors que les "pures" releases 3.16, 3.17, etc... sont gérées par Linus, mais une fois le 3.x sorti, il passe directement au 3.(x+1)(-rc<y> )
Un nouveau repo de maintenance est créé à partir du noyau de Linus, mais il est complètement indépendant.

Message édité par make install le 09-11-2014 à 11:03:47

Elbarto

bon j'ai testé le 3.16.6 --> pas de bug
le 3.16.7 --> pas de bug

le bug semble donc être dans la branche 3.17,

comment faire pour télécharger la 3.17rc1 ?

http://git.kernel.org/cgit/linux/k [...] =v3.17-rc1

quelle est la commande git pour rapatrier le code source de cette 3.17rc1 ?

j'aimerai bien la tester pour voir si le bug s'y trouve,

si je veux faire un git bisect sur la branche 3.17 je dois donc indiquer à git le commit "OK" ( qui n'a pas de bug dans cette branche 3.17 ) et un commit où le bug apparait dans cette branche 3.17, mais comment procéder car il faut identifier la plage de départ et la plage de fin au niveau des numéros des commits ?

sachant que le noyau officiel 3.17-1, 3.17.1 et 3.17.2 ont le bug

Message édité par Elbarto le 09-11-2014 à 11:43:26

make install

Tu semblais dire 3.16 good et 3.17 bad, non ?

Elbarto

oui en téléchargeant le code source du 3.17 ici et en le compilant le bug est présent :

https://www.kernel.org/pub/linux/ke [...] .17.tar.gz

et les version 3.16.4, 3.16.5, 3.16.6, 3.16.7 n'ont pas le bug,

comment procéder maintenant si je veux faire un git bisect ?

visiblement le bug a dû apparaître après le 3.16.7 et juste avant la release de la version 3.17-1, quelle est donc la stratégie à adopter si on veut faire un git bisect ?

make install

Bah pour faire un bisect, maintenant tu apprends à utiliser git
Laisse tomber les versions de maintenance si tu bisectes sur le repo de linus, elles n'ont absolument aucun rapport.
Au pire les quelques bugfix des branches de maintenance seront réintégrés dans la branche de linus pendant les rc, donc ils seront toujours entre 3.16 et 3.17 [:spamafote]

Elbarto

je m'y perds avec toutes ces branches

là je viens de faire un :

git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git

tu penses que ça sera possible de faire un bisect entre la version 3.16.7 ( commit good ) et la version 3.17 ( commit bad ) ?

make install

Oui, dans ce sens (en regardant la branche stable) ça devrait marcher.

Elbarto

ok mais je suis pas sûr de comprendre comme utiliser la commande git bisect sur la branche stable [:transparency]

je sais que le point de départ ( commit good ) est la v3.16.7, et le point d'arrivée ( commit bad ) est la version 3.17, comment ça se traduit en terme de commandes git pour le bisect ?

visiblement il faut indiquer un numéro de commit pour le point de départ et le point d'arrivée

Message édité par Elbarto le 09-11-2014 à 12:08:24

Elbarto

bon voici ce que j'ai fait :

$ git bisect start
$ git bisect bad v3.17
$ git bisect good v3.16.7
Bisecting: a merge base must be tested
[19583ca584d6f574384e17fe7613dfaeadcdc4a6] Linux 3.16

ça devrait être ok comme ça je pense, comme mon PC n'est pas très rapide ( pentium dual core E6800 3.33 Ghz ) une compilation du kernel me prend 1h15, le bisect risque donc d'être assez long mais j'espère que ça permettra de trouver le commit coupable même si ça prendra plusieurs jours de recherches

Message édité par Elbarto le 09-11-2014 à 12:17:16

make install

Oui, ça me semble bon.
Pour la compilation, tu utilises la config du kernel d'Arch ? Tu vas acoucher d'un monstre, mais ça devrait marcher.
A voir si tu clean entre chaque checkout, à mon avis t'es pas obligé, faut juste vérifier que les dates soient bien mises à jour par git.

Bon courage.

Elbarto

en fait ce que je fais c'est que je fais un copier-coller du dossier contenant la version que git que me propose, puis je compresse tout ça dans une archive linux-3.1x.tar.gz, puis j'utilise le fichier PKGBUILD qui sert à créer un paquet linux archlinux classique ( avec le fichier config qui va bien ) en l'éditant pour qu'il prenne l'archive linux-3.1x.tar.gz que j'ai crée,

comme ça ça me permet de tester avec "makepkg",

je recommence la même procédure de copier-coller dans un dossier à chaque fois que git me propose une version à tester

Message édité par Elbarto le 09-11-2014 à 20:25:57

gee

Bon ben hon

Le truc dommage c'est qu'en faisant ainsi, tu recompiles tout a chaque fois.
(mais bon de nouveau, ccache t'aiderait bien la)

---------------
"Phildar t'es vraiment une pute pas finie toi! Et Manu le gros porc arrete de t'marrer!"

Elbarto

peux-tu en dire plus sur ccache ?

comment l'utiliser ?

le but c'est de créer un paquet archlinux pour le noyau pour l'installer avec pacman, paquet qui portera le nom "linux-custom",

car je ne veux pas compiler à l'ancienne ( le ./configure, make, make install en root ),

pour l'instant j'en suis à cette étape dans le bisect :

Bisecting: 6664 revisions left to test after this (roughly 13 steps)
[39f390167e9ca73c009d3c8e2d6c3b4286b02ab6] netfilter: nft_hash: no need for rcu in the hash set destroy path

13 étapes avant de découvrir le commit coupable d'avoir introduit le bug

Message édité par Elbarto le 10-11-2014 à 00:50:17

Elbarto

j'ai trouvé cette info sur ccache et makepkg.conf :

https://wiki.archlinux.org/index.php/Ccache

à priori ça devrait être compatible avec ma méthode de copier-coller du code source vers un dossier, puis création d'un fichier linux-3.1x.tar.gz afin que le PKGBUILD le prenne en compte

Message édité par Elbarto le 10-11-2014 à 01:20:12

Publicité

Page : 1 2 3 4 5 .. 171 172 173 .. 179 180 181 182 183 184

Page Suivante

Page Précédente

Haut de page

FORUM HardWare.fr

Linux et OS Alternatifs

Débats

[Noyau Linux] Version 6 et des brouettes

Sujets relatifs
[GNU/Linux/mdk90] Mauvaise version des kernel-headers ....... [résolu]	Le Kernel Linux
Sécuriser Linux par le Kernel : LIDS ou GRSecurity ?	[Info@ZDNet][Linux]bug kernel 2.4.20 - perte de donnée
il arrive quand le linux kernel 2.4.20 dans la Debian Sarge ?	[Linux Mandrake 9] Kernel Panic :(
une carte du kernel linux très impressionnante !!	Linux --> Kernel panic
Les 'tainted kernel' , 'no license' & cie sous linux....	Mise a jour d'un kernel, je crois que je vais abandonner linux....
Plus de sujets relatifs à : [Noyau Linux] Version 6 et des brouettes

Page générée en 0.099 secondes