Linux kernel 2.4.20 (ook -pre en -rc) draadje

[Verwijderd]

En uiteraard gaat de development in volle vaart door. Linux-2.4.20-pre1 is uit. De korte announce:

So here goes -pre1, with a big -ac and x86-64 merges, plus other smaller
stuff.

2.4.20 will be a much faster release cycle than 2.4.19 was.

Wegens ontbreken van de changelog op dit moment op www.kernel.org komt ie:
Changelog
patch tegen 2.4.19

[ Voor 0% gewijzigd door Verwijderd op 06-08-2002 15:30 . Reden: Is nu beschukbaar op www.kernel.org ]

[Blubber]

Dat zijn er best wel wat Iemand hem al geprobeerd?

[Verwijderd]

Probleem is dat ie zoek is. Zo gauw deze patch opduikt zal ik mn post aanpassen en die vreselijke changelog wel linken + downloadlink.

[Blubber]

mmm oke. Hehe patch zoek, kom patchje patchje, kom maar!

[deadinspace]

Even topictitel gewijzigd... Anders denken allemaal mensen dalijk dat 2.4.20 uit is

[Verwijderd]

Draaien jullie dit echt? Zijn jullie allemaal (semi)kernel developers/testers dat jullie die patches proberen of hebben jullie steeds last van problemen met jullie huidige drivers? Ik vat werkelijk het nut niet dat je steeds bij moet blijven bij het nieuwste van het nieuwste als het huidige goed draait. Kijk als je niet tevreden bent over een specifieke driver en hij's geupdate, okay. Maarre.. dat iedereen die die patches installeert dat nou heeft.. neu, denk ik niet.

Als je zo graag een custom kernel wilt, probeer dan een kernel/patch die ook extra functionaliteit biedt ipv. een beta die niet voldoende getest is kun je problemen mee ondervinden *denkt terug aan de grapjes die zich in 2.4.x voor deden wat betreft Ext2FS* en dat waren zelfs stable versies! Want als je zo'n beta draait moet je er rekening mee houden dat 't zowel software- cq. hardwarematig in de soep kan lopen. Heb je de tijd, geld en backups dan wel klaar als het weer feest is?

Nee, ik loop liever achter. Ik laat anderen wel lekker modderen met hun nieuwste-van-het-nieuwste manie. Dus ergens ben ik ook wel blij

If it ain't broken, don't fix it!..

[Verwijderd]

Verwijderd schreef op 06 augustus 2002 @ 07:06:
Draaien jullie dit echt?

Nee.

Ik vat werkelijk het nut niet dat je steeds bij moet blijven bij het nieuwste van het nieuwste als het huidige goed draait.

Bugs eruit halen zodat de 2.4.20-final stabiel en bugfree^TM is. Als niemand die bugs eruit haalt, dan blijven ze erin zitten. Het is cutting edge, dus het nieuwste van het nieuwste. Da's de charme ervan...

Ik gebruik van een aantal drivers wel de beta versies (BTTV/zoran).

[Blubber]

En daar komt ook nog bij, tenminste dat vind ik, dat het wel leuk is om het nieuwste van het nieuwste te installeren, en dan bugs ontdekken. Vooral als deze bugs dan nog niet gemeld zijn, dan heb je ook nog het id dat je iets bijdraagd

[Verwijderd]

Oh, bughunten vind ik het probleem niet zo zeer. Dat is een goede zaak.

Alleen dit is wel een hoog risicogehalte. (Iemand zin in bughunten @ nieuwste beta Fdisk? j/k btw). Als je het nieuwste van het nieuwste wilt draaien en persee haantje de voorste wilt zijn, moet je je ook die klap in je gezicht kunnen permiteren dat er 'ns iets (goed) fout gaat. En ik heb zelf zo het idee dat niet iedereen die dit draait zich dat realiseert. Dat wilde ik dus even aan bod stellen.

Blubber schreef op 06 augustus 2002 @ 11:40:
En daar komt ook nog bij, tenminste dat vind ik, dat het wel leuk is om het nieuwste van het nieuwste te installeren, en dan bugs ontdekken. Vooral als deze bugs dan nog niet gemeld zijn, dan heb je ook nog het id dat je iets bijdraagd

Dus jij gebruikt ze wel? Waar heb je dan bugs in gevonden?

[Blubber]

Ik heb nu net FreeBSD op me testbak geinstalleerd, dus nee, deze nieuwste linux kernel heb ik nog niet geprobeerd nee. En op me fileserver ga ik dat ook niet doen . Maar ik heb ergens in de 2.4.x wel een tijdje alle nieuwe patches en zut geinstalleerd, en dan wat bugjes tegegekomen...

[Verwijderd]

Ik heb een hele poos een aantal ac patches gedraaid, maar dat was toen nodig voor mijn ATARAID array. Normaal gesproken maak ik gebruik van de laatste stable kernel. Maar ik volg de ontwikkeling van de stable kernel met interesse, vandaar de kernel draadjes.

[Blubber]

Tja, ligt er ook maar net aan wat je van plan bent met de betreffende machine. Op een belangrijke machine probeer zo een zo stabiel mogelijke kernel te draaien, dat lijkt me duidelijk. Maar soms kom je van die dingen tegen zoals ATARAID Of een Realtek RTL8139 die het niet in 2.4.18 doet Dan moet je wel... Of je downgrade natuurlijk, als dat een oplossing biedt

[Ronald]

Blubber schreef op 06 augustus 2002 @ 12:04:
Tja, ligt er ook maar net aan wat je van plan bent met de betreffende machine. Op een belangrijke machine probeer zo een zo stabiel mogelijke kernel te draaien, dat lijkt me duidelijk. Maar soms kom je van die dingen tegen zoals ATARAID Of een Realtek RTL8139 die het niet in 2.4.18 doet Dan moet je wel... Of je downgrade natuurlijk, als dat een oplossing biedt

Interessant, heb hier een vanille+preempt 2.4.18 met een werkende reuteltek 8139too (module) op een p200. Op een p90 overigens deed die module gewoon heel hard locken, zowel meegecompiled als als module. (is dat hoe het probleem zich ook bij anderen manifesteerd?? Ik heb nu namelijk een 3com in die bak zitten ipv de reuteltek wat ik eigenlijk niet wilde )

[ Voor 0% gewijzigd door Ronald op 06-08-2002 12:46 . Reden: Stukje reply beter in ander topic :) ]

[Blubber]

*denk* tis bij mij alweer een tijdje geleden, ik geloof dat modprobe 8139too idd resulteerde in een vastloper. Ik heb toen maar gedowngrade naar 2.4.17, en de bug uiteraard gemeld

[_JGC_]

2.4.19 draait een stukkie beter dan 2.4.18 op mn machine, en 2.4.20-pre1 heeft een hele belangrijke verandering tov 2.4.19 voor mn videokaartje: vmalloc gebeuren.
Sinds 2.4.19 willen de powervr drivers niet meer compileren omdat in 2.4.19 de vmalloc zooi veranderd is. in 2.4.20 zou dit weer opgelost worden, aldus de powervr FAQ.

[deadinspace]

Verwijderd schreef op 06 augustus 2002 @ 07:06:
Draaien jullie dit echt?

Nope.
Mijn bakken draaien nog allemaal 2.4.18. Waarom? Het werkt prima en ik ben lui.
Ik zal ze wel upgraden, maar dat is meer iets voor als ik zin heb.

Maar ik volg meestal wel wat nieuwtjes over kernel-development, omdat ik dat interessant vind.

If it ain't broken, don't fix it!..

Dan kun je ook wel bij 2.2.21 blijven. Maar 2.4 is toch wel sneller op sommige dingen, en biedt extra features (DRI, ext3, devfs, iptables). Zo kan het zijn dat de mga DRI driver is geupdate in 2.4.19, waardoor ik een hogere FPS in q3 zou kunnen halen. Er zitten veel IDE fixes in... Mogelijk dat dat weer scheelt op mijn mobo met VIA chipset.

Het is maar wat je als "broken" definieert

[Equator]

momenteel draai ik een Gentoo RC van 2.4.19. Ik mot nog ff wachten tot 2.4.19 opduikt in de packages van gentoo. Daarnaast wil ik wachten tot gcc 3.1 final is, dan ga ik en de kernel updaten en een "emerge system" (Met gcc3.1) doen.
Ik begreep dat dit nog wat snellere code opleverde, dus dan laat ik mijn systeempje graag een dagje compilen

[_JGC_]

gcc 3.1 is allang final, hij heeft zelfs al een opvolger: 3.1.1 (bugfix release).

[Verwijderd]

waarom deze kernel installere?? problemen met de 2.4.19? en ontwikkel je mee? ik zie het nut van deze kernel niet echt. wie heeft deze nodig??

[Blubber]

Je zou hem eventueel nodig kunnen hebben voor bijvoorbeeld hardware die in de vorige release niet of slecht werkt, en in deze release beter werkt.

[AlterEgo]

CyberJ schreef op 07 augustus 2002 @ 09:03:
Ik mot nog ff wachten tot 2.4.19 opduikt in de packages van gentoo.
Daarnaast wil ik wachten tot gcc 3.1 final is,

2.4.19 is al vanilla geworden in gentoo sinds afgelopen weekend.
Gcc 3.2 wordt de default gcc in Gentoo 1.4 (17 augustus?), en is nu nog masked.

Verwijderd schreef op 06 augustus 2002 @ 07:06:
Draaien jullie dit echt?

Zie sig

[Verwijderd]

deadinspace schreef op 06 augustus 2002 @ 23:11:
[nohtml][...]
Nope.
Mijn bakken draaien nog allemaal 2.4.18. Waarom? Het werkt prima en ik ben lui.
Ik zal ze wel upgraden, maar dat is meer iets voor als ik zin heb.

Dat ook ja, het kost tijd die je ook aan wat anders kunt besteden. Als je dus niet actief gaat bughunten of het niet gaat draaien _omdat_ het een bug fixed waar je last van ondervindt.. vind ik het wel behoorlijk nutteloos..

Dan kun je ook wel bij 2.2.21 blijven. Maar 2.4 is toch wel sneller op sommige dingen, en biedt extra features (DRI, ext3, devfs, iptables). Zo kan het zijn dat de mga DRI driver is geupdate in 2.4.19, waardoor ik een hogere FPS in q3 zou kunnen halen. Er zitten veel IDE fixes in... Mogelijk dat dat weer scheelt op mijn mobo met VIA chipset.

Het is maar wat je als "broken" definieert

Op mijn server draai ik ook 2.2.x juist omdat 2.4.x er broken op is. En 2.4.x is ook weer langzamer qua sommige dingen. Ext3FS kun je bij 2.2.x er gewoon bijpatchen en Ext3FS is trager dan Ext2FS (heb ergens testresultaten).

Maar goed ik doelde dus eik ook op devel kernels/patches niet op de stables.

[Verwijderd]

AlterEgo schreef op 07 augustus 2002 @ 22:11:
Zie sig

Hehe cadeautjes zijn idd leuk

[Verwijderd]

En jawel, een nieuwe pre is weer verschenen: Linux-2.4.20-pre2. De wijzigingen zijn weer talrijk, dus ga ik jullie niet vervelen met een kilometerlange changelog. Voor de die-hards: changelog
Je kunt de patch hier neerhalen.

[Verwijderd]

Linux -2.4.20-pre3 is uit. changelog
Je kunt de patch hier downloaden.

[ Voor 0% gewijzigd door Verwijderd op 17-08-2002 09:54 . Reden: typo ]

[Verwijderd]

wanneer wordt de 2.6 tree geopend? als 2.5 stabiel genoeg is?

[Valium]

Verwijderd schreef op 17 augustus 2002 @ 13:11:
wanneer wordt de 2.6 tree geopend? als 2.5 stabiel genoeg is?

Onder andere. Ook moeten de ontwikkelaars tevreden zijn met de nieuwe features van de kernel.

Ik heb trouwens nog 2.4.17 draaien op me servertje. Maar op me workstation (in de zin van trainstation) draai ik graag leuke patches en nieuwe spullen. Als't crasht dan kan ik me dat veroorloven, want alle belangrijke dingen staan op de server. En spelen met nieuwe buggy software is gewoon lachen. Daarom draai ik ook al mozilla sinds M8, irc ik met de beta Xchat 1.9.x etc...

Buggy software draaien is leuk. Het is actief in ontwikkeling. Je hebt er als gebruiker/betatester invloed op en je ziet een project opgroeien. Dat is gewoon leuk. Het is een van de redenen dat Linux is waar het nu is.

De uitdrukkingen "Vele handen maken licht werk" en "Vele oogballen maken elke bug triviaal. (vrije vertaling uit 't engels)" komen boven drijven.

[ Voor 0% gewijzigd door Valium op 17-08-2002 13:24 . Reden: Oeps ]

[a casema user]

dit is de patch van pre2 -> pre3
patch pre2 -> pre3

[ Voor 0% gewijzigd door a casema user op 18-08-2002 19:20 . Reden: janjansen was me weer voor ]

[Verwijderd]

pre is geen rc

[Verwijderd]

En ook pre4 is inmiddels uit. Het lijstje met wijzigingen wordt korter zoals te zien is in de changelog. De patch tegen 2.4.19 is hier te downen.

[a casema user]

hopelijk gaat dit beter dan pre3, want die wilde op een of andere reden nooit booten bij mij.

[Verwijderd]

So here goes -pre4, with JFS merged.

Also, if you got bootup lockups or some unexpected weird error try
-pre4

Die kans loop je, zie bovenstaande announce van Marcelo.

[Theguide]

Bij mij wil juist de -pre4 niet booten.
pre2-ac6-preempt doet het daarentegen prima.

[a casema user]

quote: janjanjansen

Die kans loop je, zie bovenstaande announce van Marcelo.

yup, het werkt nu wel.

En de geluidskaart wordt nu wel opeens gevonden tijdens het opstarten. Geluid deed het trouwens wel altijd, maar vond het wel grappig. (niets aan veranderd, gewoon weer als module gecompileerd).

[Verwijderd]

2.4.20-pre5 is inmiddels ook uit. Grotendeels een ac-merge.
http://www.kernel.org/pub...ting/patch-2.4.20-pre5.gz
http://www.kernel.org/pub.../testing/patch-2.4.20.log

[Verwijderd]

Zojuist zag ik een berichtje dat Linux=2.4.20-pre6 het levenslicht heeft gezien.
Haal die patch hier. Voor de liefhebber is er uiteraard een changelog.

[Verwijderd]

Er was een issue met de Interl 845 chipset. Die is opgelost in 2.4.20-pre7. Patch en Changelog .
De meeste wijzigingen zijn voor MIPS en IA64.

[rb338]

Zow, da's ook snel na pre6...
Ik denk dat de release niet lang meer duurt, of wel

_{I know, it's done when it's done, maar toch}

[Verwijderd]

Ik verwacht nog een grote merge met de ac-tree van Alan Cox. Aangezien de ac-patches nog voor 2.4.20-pre5 zijn is Alan dus nog niet helemaal klaar.

[Verwijderd]

Linux 2.4.20-pre8 is een feit. De changelog is weer eens lang. De patch tegen 2.4.19.

[Zwerver]

Verwijderd schreef op 06 augustus 2002 @ 07:06:
Draaien jullie dit echt? Zijn jullie allemaal (semi)kernel developers/testers dat jullie die patches proberen of hebben jullie steeds last van problemen met jullie huidige drivers? Ik vat werkelijk het nut niet dat je steeds bij moet blijven bij het nieuwste van het nieuwste als het huidige goed draait. Kijk als je niet tevreden bent over een specifieke driver en hij's geupdate, okay. Maarre.. dat iedereen die die patches installeert dat nou heeft.. neu, denk ik niet.

Als je zo graag een custom kernel wilt, probeer dan een kernel/patch die ook extra functionaliteit biedt ipv. een beta die niet voldoende getest is kun je problemen mee ondervinden *denkt terug aan de grapjes die zich in 2.4.x voor deden wat betreft Ext2FS* en dat waren zelfs stable versies! Want als je zo'n beta draait moet je er rekening mee houden dat 't zowel software- cq. hardwarematig in de soep kan lopen. Heb je de tijd, geld en backups dan wel klaar als het weer feest is?

Nee, ik loop liever achter. Ik laat anderen wel lekker modderen met hun nieuwste-van-het-nieuwste manie. Dus ergens ben ik ook wel blij

If it ain't broken, don't fix it!..

* Zwerver gebruikt de 2.4.20-pre[geenidee] omdat anders zijn tv kaartje niet wil werken, verder nog geen problemen mee gehad.

[a casema user]

whaaaaaaa, de eerste keer dat ik een foutmelding krijg tijdens 'make bzImage' bij het compileren van een kernel.

make[2]: Weggaan uit map `/usr/src/linux/fs/nls'
make -C partitions
make[2]: Binnengaan van map `/usr/src/linux/fs/partitions'
make all_targets
make[3]: Binnengaan van map `/usr/src/linux/fs/partitions'
make[3]: *** Geen regel voor aanmaken doel `/usr/src/linux/include/asm-ia64/efi.h', nodig voor `efi.h'. Stop.
make[3]: Weggaan uit map `/usr/src/linux/fs/partitions'
make[2]: *** [first_rule] Fout 2
make[2]: Weggaan uit map `/usr/src/linux/fs/partitions'
make[1]: *** [_subdir_partitions] Fout 2
make[1]: Weggaan uit map `/usr/src/linux/fs'
make: *** [_dir_fs] Fout 2

buggie ?

[a casema user]

2.4.20-pre9 is uit
patch tegen 2.4.19
patch pre8 -> pre9
Changelog

[Verwijderd]

Linux 2.4.20-pre10 is inmiddels uit.

download patch
Lange changelog

[a casema user]

de Changelog is relatief erg klein. Zal dit betekenen dat 2.4.20 bijna final is ?

[rb338]

Ik hoop 't
Denk eigenlijk ook wel dat ie eraan zit te komen. 2.4.19 is er nu al een tijdje en er zijn inmiddels wel genoeg pre's van .20 gekomen IMO

[Verwijderd]

En ook Linux 2.4.20-pre11 is inmiddels uit. Je kunt de patch hier downloaden.

De changelog voor de geinteresseerden.

[zwik]

Ik zie in de changelog dat er een nieuwe stv680 driver update inzit . Volgens mij gaat deze beter werken dan die oude omdat die hier nog wel eens een OOPS geeft en dan hangt het complete systeem . Ja Linux kan crashen . Voorlopig gebruik dus me webcam dus niet. Maar ik zal deze vandaag wel testen en het resultaat als het fout gaat mailen .

[a casema user]

tataaaaa
Versie 2.4.20-rc1
Changlog
2.4.20-11 -> 2.4.20-rc1 ( nog geen url voor )
2.4.19 -> 2.4.20-rc1

[Verwijderd]

Hoe lang gaat het nu nog ongeveer duren?

[deadinspace]

Paar weekjes waarschijnlijk... Vanaf de rc release is het feature-freeze en alleen nog maar bugs fixen enzo.
Hoe lang het precies duurt weet natuurlijk niemand, ik kan er ook grof naast zitten

[a casema user]

vaag
nu staat er opeens wel een patch van 2.4.20-11 -> 2.4.20-rc1

[ Voor 0% gewijzigd door a casema user op 29-10-2002 19:26 . Reden: type ]

[Equator]

Blijkbaar hebben ze dan toch nog een kleine verandering gedaan tussen pre11 en rc1
Ik hoop dat de 2.4.20 voorlopig stabiel blijkt / blijft want 2.6.0 duurt nog een aantal maanden

[rollebol]

Toch komt 2.6.0 best snel als je kijkt naar de tijd die tussen 2.2.0 en 2.4.0 zat, of vergis ik me nu heel hard in de tijd?

Maar over 2.4.20 gesproken, zijn er nog concrete redenen om van 2.4.19 naar 2.4.20 te gaan die algemeen gelden? Of zijn het alleen maar fixjes van specifieke driverbugs?

[Verwijderd]

Er worden meer gigabit nic's ondersteund

[deadinspace]

rollebol schreef op 30 oktober 2002 @ 11:29:
Toch komt 2.6.0 best snel als je kijkt naar de tijd die tussen 2.2.0 en 2.4.0 zat, of vergis ik me nu heel hard in de tijd?

januari 1999 - 2.2.0
januari 2001 - 2.4.0
juni 2003 - 2.6.0

Niet echt dus. Gek, voor mij lijkt het ook veel korter geleden

Maar over 2.4.20 gesproken, zijn er nog concrete redenen om van 2.4.19 naar 2.4.20 te gaan die algemeen gelden? Of zijn het alleen maar fixjes van specifieke driverbugs?

Echt spannende redenen zitten er zelden in de productie kernels. Misschien wat IDE driver fixes die de moeite waard zijn (dma werkte niet overal met 2.4.19), dat soort dingetjes.

[a casema user]

2.4.20-rc2 is uit !!
Changelog
patch rc1 -> rc2
patch 2.4.19 -> 2.4.20rc2

[_JGC_]

Hmm, schijnt dat ze in rc2 dat Kernel Panic lekje hebben aangepakt.

[MikeN]

_JGC_ schreef op 15 november 2002 @ 22:52:
Hmm, schijnt dat ze in rc2 dat Kernel Panic lekje hebben aangepakt.

Er zit inderdaad wel een eerste test in, maar of het afdoende is?

[e-mail]>
[PATCH] Fix lcall DoS

Hi,
your original code just behaved as my old code: run modprobe successfully,
and then die. Problem is that copy of eflags on stack is totally unimportant
to us: current value in eflags is what matters. So this is minimal
patch which works here: NT, DF and TF are now cleared only for kernel,
and when we return back from lcall, userspace has its old values.

Optimization left to readed is creating SAVE_ALL_NOCLD, and using this
one in lcall7 and lcall27.

With patch below my machine survived test. Unfortunately I do not
have patched kernel with linux-abi to test whether lcall7 still works
correctly.
Best regards,
Petr Vandrovec
[e-mail]

[Verwijderd]

En inmiddels is rc3 ook een feit. Je vindt de patch op http://www.kernel.org/pub...sting/patch-2.4.20-rc3.gz en de changelog op http://www.kernel.org/pub.../testing/patch-2.4.20.log.

[a casema user]

Voor degene die steeds elke nieuwe patch installeren.
patch 2.4.20-rc2 - > 2.4.20-rc3

[a casema user]

2.4.20-rc4 is uit
Changelog
Patch 2.4.19 -> 2.4.20-rc4
Patch 2.4.20-rc3 -> 2.4.20-rc4

[active2]

Ik zit wel te wachten tot die uit is er zit een leuke feature in iptables om eindelijk die broadcasts te loggen en te blokken

[Verwijderd]

Inmiddels is de stable released. Linux-2.4.20 en die is hier te downloaden (full version). De changelog vind je hier

[rb338]

Hij doet 't niet

Ik had m'n 2.4.19 source gepatched maar blijkbaar werkt 't toch niet zo lekker (hoewel het patchen geen problemen gaf). Mijn 2.4.19 was al gepatched met Win4Lin (2 patches), preemptive en lvcool (die niet werkte).

Als ik 2.4.20 boot, gaat ie door tot aan deze regels:

hda: 156355584 sectors (80054 MB) w/1819KiB Cache, CHS=9732/255/63, UDMA(100)
ide-floppy driver 0.99.newide

Hierna zou de partition check moeten komen (althans, dat is in 2.4.19 zo).
In plaats daarvan beginnen caps- en scroll lock te knipperen.
Ook de lvcool feature uit zetten (lvcool=off in de bootline) helpt niet.

Wat doe ik fout dan?
De patches die ik in 2.4.19 gebruik doen 't ook op 2.4.20, maar misschien veroorzaken die toch de fouten? Ik heb alleen geen zin om 2.4.20 te draaien zonder preemptive en Win4Lin

-- edit:

Ok, de lvcool patch was de boosdoener. Zelfs met lvcool=off ging 't niet goed, maar zonder die hele patch werkt 't prima. De Win4Lin mki-adapter patch doet 't alleen niet (unresolved symbols) Dan maar ff wachten tot die er is voor 2.4.20.

Verder werkt 't goed nu, de preemptive patch van 2.4.19 doet 't gewoon volgens mij

[ Voor 47% gewijzigd door rb338 op 29-11-2002 14:49 . Reden: typo ]

[voodooless]

2.4.20 (stable) is echt wel goed jongens! vooral de IO performance is erg goed, ding bij mij ~50% omhoog:

2.4.19:

/dev/hde:
Timing buffer-cache reads: 128 MB in 1.55 seconds = 82.58 MB/sec
Timing buffered disk reads: 64 MB in 2.62 seconds = 24.43 MB/sec

2.4.20

/dev/hde:
Timing buffer-cache reads: 128 MB in 1.42 seconds = 90.14 MB/sec
Timing buffered disk reads: 64 MB in 1.84 seconds = 34.78 MB/sec

Edit: specs vergeten: Celeron 333 met 256 MB. 27 GB maxtor 7200 toeren op een HPT370

[ Voor 10% gewijzigd door voodooless op 29-11-2002 15:20 ]

[rb338]

Hmm dat maakt hier verder weinig uit, in 2.4.20 heb ik:

/dev/hda:
Timing buffer-cache reads: 128 MB in 0.89 seconds =143.82 MB/sec
Timing buffered disk reads: 64 MB in 2.89 seconds = 22.15 MB/sec

Zal eens ff zoeken wat ik in 2.4.19 had, staat ook nog ergens in een topic geloof ik

edit:

Ehm, het was dus wel stukken beter:

Timing buffer-cache reads: 128 MB in 0.80 seconds =160.00 MB/sec
Timing buffered disk reads: 64 MB in 1.61 seconds = 39.75 MB/sec



edit2:

Bij nader inzien scheelt 2.4.19 niets tov 2.4.20. Het grote verschil zit 'm in LVcool: als ik dit programma uit zet stijgt m'n buffer-cache read naar 170 MB/s en buffered disk read naar 40 MB/s. Maar met LVcool blijft m'n CPU idle 10 graden koeler en stressed 4 graden en dat vind ik toch iets fijner dan die paar MB

[ Voor 53% gewijzigd door rb338 op 29-11-2002 16:07 ]

[Verwijderd]

Ik heb ook even gekeken op 1 machine maar hier maakt het bijna geen verschil, de performance is ongeveer identiek van beide kernels. Beide zo rond de 145/34. Compileren met de XFS patch ging probleemloos.

[imdos]

Ik zit nog te wachten

Op m'n server is grsecurity en op m'n client is preemptive nog niet uit

[deadinspace]

Verwijderd schreef op 29 November 2002 @ 01:10:
Inmiddels is de stable released. Linux-2.4.20 en die is hier te downloaden (full version). De changelog vind je hier

Zucht, dat is dus net een uurtje nadat ik weer een 2.4.19 had gebakken

[it0]

imdos schreef op 29 november 2002 @ 18:19:
Ik zit nog te wachten

Op m'n server is grsecurity en op m'n client is preemptive nog niet uit

Ik draai rc3 vindt niet de moeite om voor 2.4.20 te gaan.. Maar daar heb ik gewoon de laatste preemptive overheen gepatch dus dat moet met de full re lease ook gaan

Deze dus ->preempt-kernel-rml-2.4.20-pre10-1.patch

[Verwijderd]

Erm er is al een nieuwere patch uit dan jouw versie hoor, rc3-1 :

http://www.kernel.org/pub...el-rml-2.4.20-rc3-1.patch

Deze werkt perfect met 2.4.20 final, heb gisteren mijn custom kernel gecompiled :-) Met preemption & ACPI patches, werkt goed nu.

één dingetje toch nog : ofwel is de I/O bij deze versie minder goed, ofwel heb ik mijn kernel niet zo goed geconfigureerd : mijn HDD performance is gelijk gebleven (ongeveer 50MB/sec) maar mijn cache performance is een heel stuk achteruit gegaan, namelijk van 710MB/sec naar 610MB/sec! Any ideas?

[BrZ]

2.4.19:
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.02 seconds =125.49 MB/sec
Timing buffered disk reads: 64 MB in 2.67 seconds = 23.97 MB/sec

2.4.20:
/dev/hda:
Timing buffer-cache reads: 128 MB in 1.01 seconds =126.73 MB/sec
Timing buffered disk reads: 64 MB in 2.33 seconds = 27.47 MB/sec

Wel wat winst dus, maar nou niet echt spectaculair

[Verwijderd]

Ik heb pas gisteren 2.4.20 gecompiled en getest, zowel met als zonder preemptive patch
Nu heb ik alleen het vage probleem dat m'n OpenGL preformance met 30% is ingezakt. Ik heb quake3 en glxgears getest.
met glxgears heb ik op mijn 2.4.18-preempt een fps van 1200 en op de 2.4.20 en de 2.4.20-preempt 760 fps
bij quake3 is het verschil minder groot maar nogsteeds een fors verlies.
Ik draai XFree86 4.2.1.1 op een matrox g400 dualhead met de beta driver 2.0 van matrox
Heeft iemand suggesties om m'n 2.4.20 kernel qua OpenGL net zo snel te krijgen als mijn 2.4.18 kernel?

[FCA]

Ik neem dat jullie allemaal over deze data corruption bug in EXT3 in 2.4.20 hebben gelezen?
Ik vraag me alleen af hoe ik er achter kom in welke mode m'n EXT3 staat.
Nij m fstab staat als opties defaults, maar wat zijn de defaults onder Mandrake 9.0

[Jordi]

jotti@thomas:/home/jotti$ dmesg | grep -i ext3
EXT3-fs: mounted filesystem with ordered data mode.

Wel "leuke" bug weer trouwens...

[AlterEgo]

Verwijderd schreef op 06 December 2002 @ 14:37:
Ik heb pas gisteren 2.4.20 gecompiled en getest, zowel met als zonder preemptive patch
Nu heb ik alleen het vage probleem dat m'n OpenGL preformance met 30% is ingezakt. Ik heb quake3 en glxgears getest.
met glxgears heb ik op mijn 2.4.18-preempt een fps van 1200 en op de 2.4.20 en de 2.4.20-preempt 760 fps
bij quake3 is het verschil minder groot maar nogsteeds een fors verlies.
Ik draai XFree86 4.2.1.1 op een matrox g400 dualhead met de beta driver 2.0 van matrox
Heeft iemand suggesties om m'n 2.4.20 kernel qua OpenGL net zo snel te krijgen als mijn 2.4.18 kernel?

Ik heb FF hetzelfde geprobeerd met een geforce 2MX en kernel 2.4.18-preempt versus 2.4.20-preempt. ik zie geen verschil

[eth0]

Zeg ik zag dat er een paar optie er zijn begekomen in 2.4.20 nml: zlib_inflate en zlib_deflate. Deze staat nu als optie er bij weet iemand wat dit doet heb al ff gegoogle maar die geeft geen uitleg terug.

[Verwijderd]

Dat is zlib compressie en decompressie. Volgens mij gebruikt geen hond dit nog.. correct me if i'm wrong

[FrankGuthrie]

domme vraag maar wat is het verschik tussen PRE en RC kernels die uitgebracht worden? (unstable en testing ofzo?)

Ik heb de search gebruikt en weet wat RC betekent:
Een RC(release Candidate) is een release die is vrijgegeven ter test aan een selektie gebruikers.

Wat is dan het verchil met een Pre?

[Verwijderd]

Pre = Dingen adden en bugs fixen
RC = Komt na het pre proces. Dan gaan ze de bugs die gemeld zijn fixen.

Correct me if I'm wrong :+|

[Verwijderd]

PRE is nog in een testfase zonder dat er direct van wordt verwacht dat de kernel stabiel is op alle terreinen. Eigenlijk is een RC ook een PRE maar dan later in het proces. Een RC wordt uitgebracht en als het goed is worden daar geen nieuwe dingen meer in aangebracht maar slecht fixes van eventuele bugs. Een RC zonder (known) bugs wordt dan een final versie.

[eth0]

Verwijderd schreef op 26 december 2002 @ 01:49:
Dat is zlib compressie en decompressie. Volgens mij gebruikt geen hond dit nog.. correct me if i'm wrong

Duh, zover was ik ook al, maar wat precies doet het dan in de kernel.