kesako CFQ scheduler ?
c’est une nouvelle façon de gérer les I/O (entrées/sorties des périph’) très adaptée pour un usage desktop. En fait, le cfq scheduler présente des perfs moindres que l’as scheduler (celui par défaut) mais il a le merite de diminuer la latences max pour chacune des I/O traitées.
Pour mon firewall, l’intérêt est donc limité, je peux remettre mon esprit en mode tranquille 
Ok, en fait ma question portait seulement sur le “mm” de la fin 
. Si il existe plein de patchs différents, pourquoi ne parle-t-on que des “mm” ? Ils ont un caractère plus officiel que les autres ?
oui!
Andrew Norton est vraiment LE co-développeur de linux 2.6 avec Linus. Depuis qlqs versions des 2.6 de test, Linus de dit plus "I " mais “We”. Quand Linus part en vacances, Andrew devient seul responsable des 2.6 de test.
C’est la première fois que ça arrive : Avant Linus était le seul responsable de la branche en dévelo et il “donnait” la version à qlqn d’autre une fois stabilisée. Par exemple, Marchello est devenu responsable du 2.4 à partir du 2.4.11. Maintenant, c’est lui qui fait les release des 2.4. Pour les 2.2 c’est qlqn d’autre (Alan?).
Bref, Andrew, c’est un bon! un très très bon.
Les patchs mm sont donc plus offciciels que les autres.
Je pense qu’une fois le 2.6 stabilisé, Andrew va s’en occuper seul et Linus va attaquer le 2.7 (à moins qu’il trouve qlqn d’autre pour s’occuper du 2.6)
@+
Okiiii c’est bien plus clair maintenant :jap:
2.6.0-test5 dispo
pour le 2.6-test5-mm1: pour compiler il faut ce petit patch:
http://marc.theaimsgroup.com/?l=linux-mm&m=106309099428504&w=2
Sinon je viens de découvrir que pour faire un kernel, un simple make suffit (équivalent à make bzImage modules). Par conséquent, on peut créer et installer un 2.6 simplement par la commande make && make modules_install
Ah ça c pas mal
Mais pour debian on peut tjs utiliser make-pkg (ou je sais plus koa) ?
C’est une excellente question! On peut toujours utilsier make-kpkg car ça marche mais est ce la meilleure façon de faire, je n’en sais rien. (pour un 2.4, c’est la méthode sous debian)
@+
en effet ca marche… Mais on manque un peu d’info sur le sujet
mail direct au mainteneur de make-kpkg (en vérifiant qui c’est avant pour ne pas risquer de se faire “jeter” (certains dévelo debian ont le rtfm facile…))
justement je connais aucun dévelo (
C’est l’occasion de tester … 
je ne connais pas non plus le type qui s’occupe de kernel-package.
@+
test5_mm2 donc. Avec des pbs de timeout dans l’usb…
Il semble que ce soit l’apic ou l’acpi qui merdouille : on perd des IRQ.
Le framebuffer vga ne marche pas (points blancs dans tous les sens…)
Le reste marche très bien et c’est toujours aussi réactif.
@+
2.6-0-test5-mm2 > chez moi mon framebuffer marche
mais j’utilise Vesa (FB_VESA).
Tu utilises FB_VGA16 ?
j’avais mis les deux avec l’option vga=791 (ça marche avec un 2.4) mais comme c’est un peu idiot, je vais essayer avec seulement Vesa.
sortie du 2.6-0-test5-mm3.
Il tourne bien, comme le mm2.
le framebuffer vesa marche mais le mm3 ne corrige pas ce bug (connu):
uhci-hcd 0000:00:11.2: UHCI Host Controller
Sep 20 11:09:22 StEmilion kernel: Call Trace:
Sep 20 11:09:22 StEmilion kernel: [__report_bad_irq+42/144] __report_bad_irq+0x2a/0x90
Sep 20 11:09:22 StEmilion kernel: [note_interrupt+108/160] note_interrupt+0x6c/0xa0
Sep 20 11:09:22 StEmilion kernel: [do_IRQ+288/304] do_IRQ+0x120/0x130
Sep 20 11:09:22 StEmilion kernel: [common_interrupt+24/32] common_interrupt+0x18/0x20
Sep 20 11:09:22 StEmilion kernel: [do_softirq+64/160] do_softirq+0x40/0xa0
Sep 20 11:09:22 StEmilion kernel: [do_IRQ+252/304] do_IRQ+0xfc/0x130
Sep 20 11:09:22 StEmilion kernel: [common_interrupt+24/32] common_interrupt+0x18/0x20
Sep 20 11:09:22 StEmilion kernel: [pci_bus_write_config_word+97/144] pci_bus_write_config_word+0x61/0x90
Sep 20 11:09:22 StEmilion kernel: [uhci_reset+63/96] uhci_reset+0x3f/0x60
Sep 20 11:09:22 StEmilion kernel: [usb_hcd_pci_probe+405/1184] usb_hcd_pci_probe+0x195/0x4a0
Sep 20 11:09:22 StEmilion kernel: [pci_device_probe_static+82/112] pci_device_probe_static+0x52/0x70
Sep 20 11:09:22 StEmilion kernel: [__pci_device_probe+59/80] __pci_device_probe+0x3b/0x50
Sep 20 11:09:22 StEmilion kernel: [pci_device_probe+44/80] pci_device_probe+0x2c/0x50
Sep 20 11:09:22 StEmilion kernel: [bus_match+63/112] bus_match+0x3f/0x70
Sep 20 11:09:22 StEmilion kernel: [driver_attach+89/144] driver_attach+0x59/0x90
Sep 20 11:09:22 StEmilion kernel: [bus_add_driver+141/160] bus_add_driver+0x8d/0xa0
Sep 20 11:09:22 StEmilion kernel: [driver_register+47/64] driver_register+0x2f/0x40
Sep 20 11:09:22 StEmilion kernel: [pci_register_driver+95/144] pci_register_driver+0x5f/0x90
Sep 20 11:09:22 StEmilion kernel: [uhci_hcd_init+196/320] uhci_hcd_init+0xc4/0x140
Sep 20 11:09:22 StEmilion kernel: [do_initcalls+43/160] do_initcalls+0x2b/0xa0
Sep 20 11:09:22 StEmilion kernel: [init_workqueues+15/80] init_workqueues+0xf/0x50
Sep 20 11:09:22 StEmilion kernel: [init+50/352] init+0x32/0x160
Sep 20 11:09:22 StEmilion kernel: [init+0/352] init+0x0/0x160
Sep 20 11:09:22 StEmilion kernel: [kernel_thread_helper+5/12] kernel_thread_helper+0x5/0xc
Sep 20 11:09:22 StEmilion kernel:
Sep 20 11:09:22 StEmilion kernel: uhci-hcd 0000:00:11.2: irq 9, io base 00001020
donc pas de souris usb avec le mm3. Je vais voir sur la kml : il y a eu un bug report à ce sujet je crois.
Il faut aussi que je teste alsa en profondeur : que deviennent les scripts debian d’alsa-base? on peut toujours les utiliser?
@+