tu peux le compiler toi-même si ça t’amuse 
Linux 2.6.27.10
marc.info…
En lisant le changelog on voit que 90% des problème viennent de:
*accès alignés versus non alignés
- des problèmes de locks
Au passage, est ce que qlqn sait pourquoi ubuntu ne compile pas ses noyaux avec l’option qui produit /proc/config.gz ???
C’est quand même partique pour retrouver les options de compil…(ok ok on peut le retrouver dans le paquet source mais bon…quand même…)
1 - y zont pas envie ?
2 - y savent pas que ca existe ?
3 - « PPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASSSSSSQQQQQQQQQQUUUUUUUUUUUEEEEEEEEEEEEEEEEEEEEEE !!! » ?
4 - la lune n’est pas dans le bon alignement ?
5 - il manque 2 millions de budget pour ca ?
:ane:
kernelnewbies.org…
marc.info…
Je crois que c’est clair
KP2:
- possible
- m’étonnerait
- c’est CLAIR
- La lune? Je croyais que c’était jupiter qui n’était pas dans le poisson…
- tu me les donnes, je le fais (enfin si c’est des e ou des $ ou un truc dans le genre…car si c’est de brouzoufs je le fais pas ;))
- Luck Skywalker ?
Les noyaux fournis avec les distributions sont en général avec des patchs
exemple avec gentoo :
Edité le 26/12/2008 à 15:47
Oui et?
Les noyaux des distribs doivent marcher partout donc ils sont souvent un peu patcher.
Le noyo que tu compiles il doit marcher sur ta config etpicétou
1700_sparc-poweroff-hang.patch : je n’ai pas de sparc sous la main là.
4400_alpha-sysctl-uac.patch : ni d’alpha.
2500_pentax-k10d-wrong-capacity.patch : Pariel je n’ai pas ce matos
Bref, les noyaux fournis par kernel.org tournent en général parfaitement sur disons ubuntu (qui pourtant patch pas mal )
C’est vrai qu’on peut utiliser un noyau récupéré sur kernel.org, je voulais seulement dire que les différentes distribs ont l’habitude d’y ajouter qques patches en plus même si comme tu l’a précisé ils sont rarement nécessaires ou alors dans des cas très particuliers.
2.6.28.1
marc.info…
Il pourait expliquer un minimum le contenu du patch…
Le problème avec libusb n’est pas résolu partout:
marc.info…
Linux 2.6.28.2
marc.info…
Un peu d’usb et des petits fix de ci de là.
Linux 2.6.28.3
marc.info…
Un peu de tout.
Linux 2.6.28.4
marc.info…
- bp = kmalloc((sel_end-sel_start)/2*multiplier+1, GFP_KERNEL);
- bp = kmalloc(((sel_end-sel_start)/2+1)*multiplier, GFP_KERNEL);
Postulat : Tout code complexe contient ce genre d’erreur.
Heu le 2.6.28.5 a véçu combien de temps??
www.clubic.com… : Cinq jours
On a vu beaucoup plus court…
Bon j’ai loupé le .7
2.6.28.8
« The it87 driver is reporting -128 degrees C as +128 degrees C.
That’s not a terribly likely temperature value but let’s still get it right, especially when it simplifies the code. »
Un patch fondamental
linuxfr.org…
et donc surtout
lwn.net…
Linux 2.6.29.1
marc.info…
Un peu de tout…
Linux 2.6.29.2
There are a lot of fixes in this release touching all over the tree.
At least a few have possible security impact (e.g. af_rose, agp,
capability fs_mask, splice/ocfs2). As usual, you’re encouraged to
upgrade. For details see the short changelog and diffstat below or full
changelog on kernel.org.
Linux 2.6.29.3
« All users of the 2.6.29 kernel series are very strongly encouraged to upgrade. » aka « ya du gros bug qui traine »
Linux 2.6.29.4
marc.info…
un peu de tout
Le noyau Linux 2.6.30 est disponible
tu parles d’un bug : le sync n’est pas fait automatiquement lors du close dans la VFS. Du coup si tu temporise tes écritures tu l’as dans le c*** et tu te retrouves avec un fichier vide.
Et devines quoi? ext4 ainsi que tous les FS moderne (post ext3) temporisent de plusieurs secondes pour faire des écritures par bloc moins coûteux, et avoir la meilleure stratégie contre la fragmentation …
du coup si tu ne démontes pas normalement le FS, tu ne force pas ton sync final, et paf les données...
Le plus drôle c'est que le bug était présent depuis linux 1.x, mais grace à des FS moins perfectionnés il était presque impossible de mettre le bug en évidence.