Qu’on soit dans la branche 2.4 ou dans la branche 2.6 ou ailleurs, ça reste une rc1. Je ne l’ai pas encore testée.
Le changelog est encore très gros :
"Ok, this is another big merge of a number of pending patches, although to
some degree the patches have now moved « outwards » from the core, and most
of them are in driver land.
There’s a lot of network driver updates (have been in -mm and Jeff’s
testing trees for a while), and Al Viro has been fixing up not just
network drivers, but also cursing over parport interfaces
Andrew’s patches are all over, from fixing warnings with new versions of
gcc to merging things like the ppc updates he had in his tree, and
everything in between.
On and a big ALSA update, along with SCSI updates (big qla update, for
example).
So let’s calm down and make sure all the updates are ok.
Linus"
« let’s calm down » : Faut il comprendre : « Je voudrais bien commencer le 2.7 ;) »
avec le 2.6.2-mm1, j’ai l’ému scsi qui est complêtement bugguée. Je dois graver en pur ide sinon k3b ne démarre même pas. Le prob se situe lors des tests de config du graveur au démarrage de l’appli. Chose intéressante, la led de mon dd reste allumé, comme si le module ide_scsi essayait d’accéder à mon dd et non à mon graveur. Je remarqué ce comportement avec d’autres applis qui testent les lecteurs comme totem. La console me donne une erreur de timeout scsi. Lorsque je faits un rmmod -f ide-scsi, ma led s’étteint mais l’ordi freeze.
Par contre, aucun prob en mode ide.
sT0ne : je suis en train de graver en emu scsi ss ce même noyau. Au premier démarrage, j’ai eu un pb de droit sur cdrecord, facilement résolu en relançant K3bconfig, puis, j’ai relancé K3b, et pas de souci.
kyo > Non tu ne réves pas, c’est bien le cas. Par contre, depuis quelques versions, les patchs mm intégrent même les patchs alsa-bk, ce qui signifie que les patchs mm vont plus loin que de simplement intégrer la dernière version stable d’ALSA.
Au fait, je viens de remarquer, dans le paquet alsa-driver, ya un rep « alsa-kernel ». Ne suffit-il pas de copier son contenu dans le répertoire sound du noyau avant de compiler pour profiter d’un alsa à jour ?
v10ware > Non ce n’est pas suffisant. Déjà, il faut déplacer les include. Je l’ai déjà fait 2-3 fois et j’ai dû en plus commenter certaines lignes du KConfig dans …/linux/sound (lignes 35 et 81).
En fait alsa-driver fourni un petit script qui devrait faire cela proprement mais je n’ai pas réussi à le faire marcher.
Uhhuh. There was a bit more pending, so here’s a -rc2. Now please calm
down, I’d like this to have some time to stabilize…
The rc1->rc2 changes are mostly driver side stuff: PnP update, USB, ACPI,
IRDA, i2c, hotplug-PCI and netdrivers etc. But there’s a NFSv4 update and
soem XFS fixes there too.
non, je suis encore au dernier mm [:yeoh]
[fixed]Linux phoenix 2.6.3-rc1-mm1 #2 Tue Feb 10 00:59:24 UTC 2004 i686 AMD Athlon™ XP 2400+ AuthenticAMD GNU/Linux[/fixed]
[fixed]
[root@roquetav pynfs]# ./nfs4client.py 172.16.109.31:/
nfs4: >ls
operation OP_PUTFH returned result NFS4ERR_PERM
nfs4: >cd vincent
nfs4: /vincent>ls
operation OP_PUTFH returned result NFS4ERR_PERM
nfs4: /vincent>cat test
Error fetching file: operation OP_PUTFH returned result NFS4ERR_PERM
evidement
ls -l /mnt/nfs
drwxrwxrwx 23 4294967294 4294967294 4096 fév 11 18:28 vincent
[/fixed]
et avec vi, beau délire
[fixed]
ls -l .
. …
vi test.c
->:q!
ls -l
. … .test.swp.O
[/fixed]
Ca ressemble à un buffer du cache qui n’est pas flushé mais la galère pour trouver où…
(j’ai testé avec plusieurs noyau, alsa toujours compilé en dur)