Linus Torvalds: Linux 2.6.21-rc4

Kernel

Linus kiadta a 2.6.21-es Linux kernel negyedik kiadásra jelölt verzióját. Ahogy Linus írja, a patch számos random javítást tartalmaz. Reméli, hogy az -rc4-gyel komoly mértékben csökkentették a korábban Adrian Bunk segítségével felállított regressziókat tartalmazó listát. A bejelentés itt.

( Troppauer | 2007. 03. 17., szo – 17:57 )

Azt nem tudom, hogy hova a fenebe fejlesztenek ilyen gyorsan, az egyik kernel rosszabb mint a masik, Nekem a 2.6.18.7 is fagy meg a 2.6.19.2 is es a 2.6.20 is. Persze kulonfele gepeken, a kulonfele kernelek. Az egyik gepen jol megy, a masikon nem. Jelenleg a legmegbizhatobb kernel. a 2.6.16.43-as (szerintem).
Siralmas, hogy ha pl talalnak egy hibat a 2.6.19-ben, akkor azt nem javitja senki az elozokben(tudomasom szerint), "csak" a 2.6.16-ba portoljak vissza (mar ha a funkcio ott letezett)

Regen nem volt ilyen sok gond, vagy csak en erzem igy?

Ez egy debian sarge, egy kicsit regi a szallitott kernel :( sajna van nehany driver ami kellene.

pl kivonal a 2.6.16.43 changelogjabol: 


Commit: b2afa146899caaa55e49839a21e0c98f504e05ad 
Author: Patrick McHardy <kaber@trash.net> Mon, 26 Feb 2007 23:47:11 +0100 

    [DECNET]: Fix sfuzz hanging on 2.6.18
    
    Dave Jones wrote:
    > sfuzz         D 724EF62A  2828 28717  28691                     (NOTLB)
    >        cd69fe98 00000082 0000012d 724ef62a 0001971a 00000010 00000007 df6d22b0
    >        dfd81080 725bbc5e 0001971a 000cc634 00000001 df6d23bc c140e260 00000202
    >        de1d5ba0 cd69fea0 de1d5ba0 00000000 00000000 de1d5b60 de1d5b8c de1d5ba0
    > Call Trace:
    >  [<c05b1708>] lock_sock+0x75/0xa6
    >  [<e0b0b604>] dn_getname+0x18/0x5f [decnet]
    >  [<c05b083b>] sys_getsockname+0x5c/0xb0
    >  [<c05b0b46>] sys_socketcall+0xef/0x261
    >  [<c0403f97>] syscall_call+0x7/0xb
    > DWARF2 unwinder stuck at syscall_call+0x7/0xb
    >
    > I wonder if the plethora of lockdep related changes inadvertantly broke something?
    
    Looks like unbalanced locking.
    
    Signed-off-by: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>
    Signed-off-by: Adrian Bunk <bunk@stusta.de>

Ez egy 2.6.18-ban felfedezett hiba, amit backportoltak a 2.6.16-ba.

Nemcsak onnan emeltek be pecseket, számos más driver_ és egyéb fix is található benne a vanilla 2.6.18hoz képest.

Egy próbát mindenképp megér, hátha a motyód elmegy vele. Ha nem, akkor se reménytelen a helyzet, ha javították vmely vanilla kernelben, vagy rcben a hibát, akkor elérhető a javítás a git.kernel.org(?)on, és akkor lehet elég csak a javítást hozzápolcolnod egy "szimpatikus" disztró kernelhez.

--------

Nem a zsömle kicsi, a pofátok nagy...

+1

Ha az ember saját kernelt fordit, akkor felelősséggel tartozik (a néhány esetben distrónak is) megfelelő konfigért, ha pedig distró által szállitottal, akkor a megfelelő hibakeresésért. (dmesg, hardver-BIOS áttanulmányozása, stb).

Ezek is lehetnek a gyenge láncszemek.

Vagy akár a hardver. Nekem egy SiS és egy ATI chipsetes (laptop) alaplapnál voltak feltűnően érdekes problémáim.

És jó sok mindent használsz aminek számítana?

Pl. nvidia v. ati driver, vmware, egyéb 3rd parti kernel driver-ek stb.

nem véletlen vannak a distrok kernelei szanaszét pecselve a vanilla kernelekhez képest.

Nagyon drukkolok a linux-nak, és is használom ha tehetem, de ez a kernelfejlesztő banda tiszta káosz...

Szokásos vesszőparipám mindent elmond erről:

miért nincs linux-ra egy kiforrott, mindig használható crashdump (és analízis) tool?

Látom nem értik a kollégák a probléma mibenlétét...

Az hogy esetleg ki tudom korrektül dump-olni a memóriát, és esetleg ki tudom olvasni a "message ring buffer" tartalmát az egy dolog...

Az pedig megint egy másik dolog hogy aztán korrekt módon elemeznis tudjam hogy meg tudjam mondani egy vállalati ügyfélnek hogy miért hasalt el a gépe, adott driver-rel volt-e a probléma, esetleg éppen mi okozhatta a performancia problémáját.

Ehhez ugyebár stabil API és ABI kellene ami nem hetente-havonta változik és dokumentálva is van.

Innentől kezdve lehetne aztán tool-okat is írni hozzá és "tudomány/művészetté" fejleszteni.

Mint tudjuk a linux "moving target" ad-hoc ötletekkel, fejlesztésekkel sokszor.

Ezért nem lehet linux esetében korrekt crashdump és analízisről beszélni.

"miért nincs linux-ra egy kiforrott, mindig használható crashdump (és analízis) tool?"

Azt nem tudom, de lazán kapcsolódik, hogy olyan eszköz sincs, ami segíthetné a desktop alkalmazások fejlesztőit az alkalmazásaik sebességre optimalizálásában. Hogy miért? Állítólag:

The kernel people do not know what we need to really profile applications for I/O and memory access

Lehet, hogy a te problémád hátterében is hasonló ok húzódik.

"miért nincs linux-ra egy kiforrott, mindig használható crashdump (és analízis) tool?"

Kdump, A Kexec-based Kernel Crash Dumping Mechanism

"Kdump is a kexec based kernel crash dumping mechanism, which is being perceived as a reliable crash dumping solution for Linux"

(AFAIk 2.6.20 óta része a mainline Linux kernelnek, az IBM fejleszti, és szerintük megbízható debug eszköz)

--
trey @ gépház