Kernel 2.5.x en pre 2.6.0 draadje....

[voodooless]

Voor de rest: geen idee... Heb je laatste versie van xawtv?

Ja ik heb de laatste versie van xawtv

Fullscreen kan ook via overlay met Xv-capable videokaarten.

Dat is toch precies dat wat grabdisplay doet of heb ik dat nu mis?

[Verwijderd]

deepspace schreef op 29 March 2003 @ 01:56:
Dat is toch precies dat wat grabdisplay doet of heb ik dat nu mis?

Nee. Grabdisplay gabt frames via DMA naar je mem, scalet ze in software naar fullscreen en schrijft dat naar een X11 window, of schrijft dat direct naar de YUV/Xv scaler. Overlay+Xv met Load "v4l" in de modules sectie van je XF86Config-4 doet directe PCI->PCI of PCI->AGP DMA van je TV kaart naar je videokaart's Xv scaler. Dit wordt ook nog eens aan de X server side gedaan, waardoor het synchroon loopt en dus veel minder stotterig overkomt (en de zwarte flash die je bij normale overlay soms ziet, zie je hier niet).

[voodooless]

Thanks ik zal het eens proberen! Alleen jammer dat je dan geen filters meer kunt gebruiken..

[wouzer]

Verwijderd schreef op 28 March 2003 @ 22:21:

C:

static inline int try_module_get(struct module *module)
{
        int ret = 1;
                                                                                
        if (module) {
                unsigned int cpu = get_cpu();
                if (likely(module_is_live(module)))
                        local_inc(&module->ref[cpu].count);
                else
                        ret = 0;
                put_cpu();
        }
        return ret;
}

Oftewel, als de module alive is, dan inc je de refcount, maar de return value is dan 1 (=error)?!? En anders inc je de refcount niet maar de return value is dan 0 (=success)? Hoe werkt dit in godsnaam? Waar is de documentatie in /usr/src/linux/Documentation/*? (Ja ik weet dat online documentatie is, maar die wil ik in de kernel tarball).

Najah, zo kan ik nog wel ff door gaan. Dit ding is nog lang niet klaar voor primetime. .

In C is 0 false en de rest true.

[Verwijderd]

wouzer schreef op 29 March 2003 @ 11:19:
In C is 0 false en de rest true.

I know, maar dit is geen if (). Dit is een ACK. 0 is ACK, alles lager dan nul is error (return value is error code).

Achteraf bleek overigens dat 1 okee is en 0 error - lekker gedocumenteerd weer. . Waarom 'ie dan 1 returnt als module NULL is, is me compleet onduidelijk.

[Verwijderd]

Verwijderd schreef op 29 March 2003 @ 18:26:
[...]


I know, maar dit is geen if (). Dit is een ACK. 0 is ACK, alles lager dan nul is error (return value is error code).

Achteraf bleek overigens dat 1 okee is en 0 error - lekker gedocumenteerd weer. . Waarom 'ie dan 1 returnt als module NULL is, is me compleet onduidelijk.

Het is duidelijk een programmeer denk fout. Kortom foutje. Komt voor..

[ Voor 6% gewijzigd door Verwijderd op 29-03-2003 19:13 ]

[Verwijderd]

Normaal gesproken documenteren mensen dit soort externe interfaces... .

[Verwijderd]

FYI: http://mjpeg.sourceforge....nux-zoran-driver.patch.gz .

/me hoopt dit binnenkort in de kernel te vinden.

[Bart Coppens]

En hier hebben we 2.5.67
patch
full

[pleuris]

Nou die 2 links zijn dood dus je bent iets te vroeg....

[Bart Coppens]

Heel kernel.org is dood hier Dus dat ze dood zijn kan ik best begrijpen, ja In ieder geval is hij gereleased, de mailtjes van Torvalds en kernel-announce zeggen dat hij uit is, dus is hij uit. Aangezien kernel.org dood lijkt hier ff de 'comment':
All over the place as usual - there's definitely a lot of small things
going on. PCMCIA and i2c updates may be the most noticeable ones.

[Verwijderd]

Ik heb 2.5.66 ook maar is geprobeerd....met coda was het resultaat een oops bij 't booten, zonder coda werkte het wel redelijk. Iemand anders wel is coda support geprobeerd?
btw. coda support gebruik ik voor davfs

[Verwijderd]

En meteen maar nieuwe patch d'r achteraan gegooid... Hopen dat ze nu geen kilo's i2c veranderingen gaan doen en dat mijn patch er nu wel "gewoon" in mag. .

http://mjpeg.sourceforge....nux-driver-zoran.patch.gz

[MadEgg]

Hmmz... het enige wat ik krijg nadat ik Linux Development Kernel selecteer in grub is een rebootende machine

[Bigs]

Verwijderd schreef op 26 March 2003 @ 19:32:
ik heb kernel 2.5.66 gecompileerd met alle nodige modules enz, maar als ik boot krijg ik deze meldingen (deze is voor mijn pcmcia draadloze netwerkkaart) maar ik krijg er ook voor usb muis, toetsenbord enz
Mar 26 15:31:11 localhost cardmgr[495]: socket 0: Aironet PC4800
Mar 26 15:31:11 localhost cardmgr[495]: executing: 'modprobe airo_cs'
Mar 26 15:31:12 localhost cardmgr[495]: + modprobe: QM_MODULES: Function not implemented
Mar 26 15:31:12 localhost cardmgr[495]: +
Mar 26 15:31:12 localhost cardmgr[495]: + modprobe: QM_MODULES: Function not implemented
Mar 26 15:31:12 localhost cardmgr[495]: +
Mar 26 15:31:12 localhost cardmgr[495]: + modprobe: Can't locate module airo_cs

De output van cat /proc/modules geeft dat er geen enkele module geladen is
Mod-utils en mod-init-tools zijn al geupgrade

Dit krijg ik inderdaad ook.. iemand daar tips voor? Ik heb gewoon module support in m'n kernel en de laatste modutils versie.

[Verwijderd]

Bigs schreef op 07 april 2003 @ 23:08:
Dit krijg ik inderdaad ook.. iemand daar tips voor? Ik heb gewoon module support in m'n kernel en de laatste modutils versie.

module-init-tools installeren.

[AlterEgo]

Nu 2.5.67 er wel echt is en er wel kilo's i2c verbeteringen inzitten, vraag ik me af of iemand lm_sensors aan de gang heeft weten te krijgen met deze versie.
De modules/sensors die ik nodig heb, zitten inmiddels in deze kernel versie.
Voorzover ik de changelogs en de docs begrijp, is de module "i2c-proc" vervallen. "sysfs" Is het platform waar de waarden van de sensors worden beschikbaar gemaakt, de vervanging van /proc/sys/dev/sensors :

Each chip gets its own directory in the sysfs /sys/devices tree. To find all sensor chips, it is easier to follow the symlinks from /sys/i2c/devices/

Alle modules modproben prachtig, maar wat gebruik ik als vervanger van i2c-proc om ook echt data te kunnen uitlezen:?

( De lm_sensors website en de cvs-versies van i2c en lm-sensors leveren geen betere documentatie op dan bij de kernel zit (en ook geen werkende modules)).

[Wirf]

2.5.67 is bagger voor mij; Panics (met dataloss zelfs) als ik een shutdown doe en zonet een freeze toen ik mijn monitor uitdeed (monitor heeft ook een USB hub)

ik ga dus weer terug naar 2.5.66

[Verwijderd]

Wirf schreef op 09 April 2003 @ 15:50:
2.5.67 is bagger voor mij; Panics (met dataloss zelfs) als ik een shutdown doe en zonet een freeze toen ik mijn monitor uitdeed (monitor heeft ook een USB hub)

Hebben ze dan toch de standby functie van win98 geïmplementeerd?

[Verwijderd]

AlterEgo schreef op 08 april 2003 @ 19:56:
Nu 2.5.67 er wel echt is en er wel kilo's i2c verbeteringen inzitten

Verbeteringen m'n neus! 99% onzin, het enige goede is device-system support (daarmee kun je mooie statistiekjes van je hardware in /proc zetten), voor de rest gewoon andere naam zelfde prut. Ik vind die rewrite onzinnig.

[AlterEgo]

Verwijderd schreef op 09 April 2003 @ 19:29:
[...]


Verbeteringen m'n neus! 99% onzin, het enige goede is device-system support (daarmee kun je mooie statistiekjes van je hardware in /proc zetten), voor de rest gewoon andere naam zelfde prut. Ik vind die rewrite onzinnig.

Ik citeerde ene Beelzebubu verkeerd: Hij zei inderdaad "veranderingen" en niet "verbeteringen". Sorry about that _{wel een gevoelige snaar geraakt}

Ik vind verregaande integratie van hardware-sensors in de kernel een goede en logische stap.
En als dat ingrijpende wijzigingen vereist in een development-kernel: so be it.

[Verwijderd]

De hardware-sensors waren volgens mij niet de reden van de i2c veranderingen... In elk geval niet van de 2.5.66 -> 2.5.67 veranderingen. Ik kan je wel een API diff geven, maar als ik het zo zie dan is er niks veranderd behalve dat er enkele shortcut functies zijn gekomen (en die moet je dan gelijk gebruiken. ) en dat enkele variabelen op een andere plaats terecht zijn gekomen waardoor je overal iets moet doen als:

C:

static struct i2c_client my_client_template = {
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,5,0)
        .dev = {
                .name = "my_client"
        },
#else
        .name = "my_client",
#endif
}

Het stomste is nog dat andere 'handigheids' functies er net zo hard weer zijn uitgehaald (i2c_client_{inc,dec}_use() bijvoorbeeld, je moet nu direct try_module_get() en module_put() gebruiken)... Dan vraag ik me af: Waarom?!?

Maargoed, ik ben maar een armzalige pruts0r en de i2c-heren zijn 1337 en zij zullen het dus wel beter weten. .

[loial]

Goh, ik dacht ook maar eens 2.5.67 te bakken, en wel de mm variant,
maar dat doet er nu even niet toe.
Ik krijg vrolijk een compile error als ik de module voor mijn RAID kaart compile:

code:

gcc -Wp,-MD,drivers/scsi/.dpt_i2o.o.d -D__KERNEL__ -Iinclude -Wall
 -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common
 -pipe -mpreferred-stack-boundary=2 -march=pentium3
 -Iinclude/asm-i386/mach-default -nostdinc -iwithprefix include
 -DKBUILD_BASENAME=dpt_i2o -DKBUILD_MODNAME=dpt_i2o -c
 -o drivers/scsi/dpt_i2o.o drivers/scsi/dpt_i2o.c
drivers/scsi/dpt_i2o.c:32:2: #error Please convert me
 to Documentation/DMA-mapping.txt
drivers/scsi/dpt_i2o.c: In function `adpt_scsi_to_i2o':
drivers/scsi/dpt_i2o.c:2139: structure has no member named `address'
drivers/scsi/hosts.h: At top level:
drivers/scsi/dpt_i2o.c:165: warning: `dptids' defined but not used
make[2]: *** [drivers/scsi/dpt_i2o.o] Error 1
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2
CP10860-b linux-beta #

Het probleem is dat ik die al eens eerder gehad heb, in 2.5.5x ergens, dat weet ik niet meer precies. Ik dacht, nou iemand merkt dat wel. Niet dus, het werkt nog steeds niet. Ik kijk in de dpt_i2o.c file en zie een email adres staan, meel er naar toe... blijkt die persoon inmiddels ontslagen bij Adaptec. Fijn! Kvraag me af of het wel verstandig van me was een mailtje te sturen naar de support afdeling van adaptec, ik denk eigenlijk niet dat die de developmentkernel actief volgen
Maar goed, morgen krijg ik wel antwoord, ben benieuwd.
Weet iemand waar ik anders heen moet? Khoef toch niet naar de kernel mailinglist te schrijven he ?

[Verwijderd]

Ik denk van wel... Alhoewel zij je naar de support afdeling van Adaptec zullen doorverwijzen, die maintainen de module, geloof ik.

[Verwijderd]

Wat houdt de mededeling "bad: scheduling while atomic" in? (kernel 2.5.66)

[loial]

Woot, komt m'n college Inl. Parallel Programmeren toch nog van pas
atomic wil zeggen dat het niet onderbroken mag (KAN!) worden. Blijkbaar gebeurt dat toch....de scheduler wil een ander programma laten runnen...

[bkor]

2.5.68

announcement:

Tons of changes all over the map. The diff is large, partly because the s390x support got merged into the s390 port as a 64-bit subset, and the old s390x architecture files thus became irrelevant. And a merge with Alan gave us a another architecture instead - h8300.

Lots of dvb updates (digital video), again through Alan. And a major aic79xx driver update.

Oh, and the devfs stuff by Christoph means that devfs users should beware: in particular, devfs users need to mount the pts filesystem like everybody else does, that duplication got killed.

Other than that, just a ton of updates. See changelog for details.

Linus

Patch
Changelog
Source tarball

[Verwijderd]

Oh, and the devfs stuff by Christoph means that devfs users should beware: in particular, devfs users need to mount the pts filesystem like everybody else does, that duplication got killed.

Hmm, dus je kan devfs en pts niet naast elkaar draaien met deze kernel?

[Verwijderd]

Loial schreef op 11 April 2003 @ 16:24:
Woot, komt m'n college Inl. Parallel Programmeren toch nog van pas
atomic wil zeggen dat het niet onderbroken mag (KAN!) worden. Blijkbaar gebeurt dat toch....de scheduler wil een ander programma laten runnen...

En hoe kan ik dat oplossen? Zou 't met devfs en/of ide tagged command queing te maken hebben?

[Verwijderd]

Verwijderd schreef op 20 april 2003 @ 10:51:
[...]
Hmm, dus je kan devfs en pts niet naast elkaar draaien met deze kernel?

mjawel, zonder /dev/pts was ik me *terms kwijt

Ik heb het opgelost door /dev/pts ook mee te compilen en dan de volgende entry te maken in /etc/fstab:

code:

devtps /dev/pts devpts default 0 0

Ik zag dat de via686a/b I2C er nu ook in zit
Nog niet aan de praat gekregen, maarja heb ik weer wat te doen

kreeg net ook kernel-panic/oops na kernel-panic/oops bij het rebooten, maar ging te snel om te zien waar aan het nou lag (zag even snel iets met mm/allocate ofzo.. heb er voor de rest geen verstand van maar zal wel zitten in

page_alloc.c of page_alloc.o of vmalloc.c of vmalloc.o

[ Voor 4% gewijzigd door Verwijderd op 20-04-2003 16:38 . Reden: even post aangepast zodat het ook echt een reply was :x ]

[neographikal]

hmmja, maar als ik de vga=xxx spcificeer in de lilo.conf krijg ik nog steeds geen beeld op de console (ati mobility 9000). K heb de radeon driver geladen maar werken ho maar

[Verwijderd]

Ik heb gisteren een 2.5 Kernel gecompileerd. Ik lees overal dat je met de nieuwe scheduler X renice moet uitzetten. Ik kan alleen niet vinden waar Debian dat doet. In Welke configuratie file staat dat?

[Freak_NL]

Standaard wordt je X-server niet geniced dacht ik, maar van Debian weet ik dat niet zeker.

Als je in X zit, voer dit eens uit:

code:

renice 0 `pidof X`

Hiermee renice je X op 0 (geen nice dus), maar het commando toont ook de vorige prioriteit. Als die op 0 stond is er niets aan de hand en wordt je X-server niet gereniced door de bootscripts.

Ik heb met 2.5.67 wel een paar X-hangs gehad.. X bevriest volledig, xmms loopt nog even door tot het einde van het nummer en stopt ook. Het beeld blijft gewoon staan. Het rare is dat ik via ssh nog gewoon alles kan doen behalve X doodmaken (kill -9 niet.. hoe dan wel??). Vaag, zal m'n kernelboom eens naar 2.5.68 patchen.

[Buffy]

Verwijderd schreef op 20 April 2003 @ 19:34:
Ik heb gisteren een 2.5 Kernel gecompileerd. Ik lees overal dat je met de nieuwe scheduler X renice moet uitzetten. Ik kan alleen niet vinden waar Debian dat doet. In Welke configuratie file staat dat?

In debian kan je in /etc/X11/Xwrapper.config een nice value opgeven.

Je kan het met de hand aanpassen (zie commentaar in het bestand) of via dpkg-reconfigure xserver-common.

[AlterEgo]

Verwijderd schreef op 20 april 2003 @ 16:29:
[...]

code:

devtps /dev/pts devpts default 0 0

Niet om te zieken ofzo, maar voor de blinde copy-pasters:
zo is ie zonder typo's:

code:

devpts  /dev/pts    devpts  defaults    0 0

[Semetrix]

oe mja dom :x
maar maakt niet zoveel uit tis alleen een 'naam' die je definieerd

[edit]
argh waarom staan er hier andere mensen ingelogd :x

[ Voor 32% gewijzigd door Semetrix op 22-04-2003 22:48 ]

[rb338]

Ik lees bij de t.net software update voor kernel 2.5.68 dat de syntax van de vga=xx commandline is aangepast en daarom niet werkt.

Probleem is, ik kan hier weinig over vinden. Ofwel: wat is de nieuwe syntax

[blouweKip]

Ik lees bij de t.net software update voor kernel 2.5.68 dat de syntax van de vga=xx commandline is aangepast en daarom niet werkt.

Gek, aangezien het bij mij (2.5.68 met mm-patches) nog gewoon werkt met de "oude" syntax

[rb338]

Ja, bij mij dus niet.. en bij veel mensen niet..

Ik gebruikte altijd vga=31A, werkte perfect met 2.4.x...
Nu met 2.5.x krijg ik alleen maar zwart beeld

Is de rivafb driver nog brak ofzo?

[blouweKip]

waarschijnlijk moet je gewoon vesa gebruiken, die rivafb of atifb zijn toch alleen maar nuttig als je ze veel gebruikt (via framebuffer films kijken ofzo, of directfb gebruken)

[Niek]

rb338 schreef op 23 april 2003 @ 12:33:
Ja, bij mij dus niet.. en bij veel mensen niet..

Ik gebruikte altijd vga=31A, werkte perfect met 2.4.x...
Nu met 2.5.x krijg ik alleen maar zwart beeld

Is de rivafb driver nog brak ofzo?

De vga=blabla optie is _alleen_ voor vesafb. Als je rivafb wilt gebruiken, moet je iets als "video=rivafb:1024x768-24@85" gebruiken. Dat werkt perfect bij mij.

[Verwijderd]

rivafb was toch bijna niet bruikbaar omdat hij niet samenwerkte met de nvidia drivers. (en dan kan je OpenGL wel vergeten...)
dus met nvidia kaarten moet je vesafb gebruiken?

[Niek]

Verwijderd schreef op 23 april 2003 @ 16:57:
rivafb was toch bijna niet bruikbaar omdat hij niet samenwerkte met de nvidia drivers. (en dan kan je OpenGL wel vergeten...)
dus met nvidia kaarten moet je vesafb gebruiken?

Dat _was_ zo ja. De huidige rivafb driver in de 2.5 kernel heeft dit probleem niet meer. Werkt perfect samen met X.
(Er is trouwens ook een soort backport van die driver voor 2.4.20, zie http://www.ussg.iu.edu/hy...x/kernel/0212.2/1414.html)

[wzzrd]

Misschien een te-dom-om-te-poepen vraag, maar "Riva" slaat dat op Riva 128 en TNT kaarten of kan mijn GF4Ti4200 in theorie ook met die rivafb werken?

[Niek]

wzzrd schreef op 23 april 2003 @ 18:48:
Misschien een te-dom-om-te-poepen vraag, maar "Riva" slaat dat op Riva 128 en TNT kaarten of kan mijn GF4Ti4200 in theorie ook met die rivafb werken?

Check de source Het werkt in 2.5 (of met die backport) AFAIK op alle TNT/Geforce (2/3/4, MX en Ti) kaarten.

code:

niek@tussen niek $ grep GEFORCE /usr/src/linux/include/linux/pci_ids.h
#define PCI_DEVICE_ID_NVIDIA_GEFORCE_SDR               0x0100
#define PCI_DEVICE_ID_NVIDIA_GEFORCE_DDR               0x0101
#define PCI_DEVICE_ID_NVIDIA_GEFORCE2_MX               0x0110
#define PCI_DEVICE_ID_NVIDIA_GEFORCE2_MX2              0x0111
#define PCI_DEVICE_ID_NVIDIA_GEFORCE2_GO               0x0112
#define PCI_DEVICE_ID_NVIDIA_GEFORCE2_GTS              0x0150
#define PCI_DEVICE_ID_NVIDIA_GEFORCE2_GTS2             0x0151
#define PCI_DEVICE_ID_NVIDIA_GEFORCE2_ULTRA            0x0152
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_MX_460           0x0170
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_MX_440           0x0171
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_MX_420           0x0172
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_440_GO           0x0174
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_420_GO           0x0175
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_420_GO_M32       0x0176
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_440_GO_M64       0x0179
#define PCI_DEVICE_ID_NVIDIA_IGEFORCE2                 0x01a0
#define PCI_DEVICE_ID_NVIDIA_GEFORCE3                  0x0200
#define PCI_DEVICE_ID_NVIDIA_GEFORCE3_1                        0x0201
#define PCI_DEVICE_ID_NVIDIA_GEFORCE3_2                        0x0202
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_TI_4600          0x0250
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_TI_4400          0x0251
#define PCI_DEVICE_ID_NVIDIA_GEFORCE4_TI_4200          0x0253

[AlterEgo]

The_Surfer schreef op 23 April 2003 @ 18:27:
[...]
Dat _was_ zo ja. De huidige rivafb driver in de 2.5 kernel heeft dit probleem niet meer. Werkt perfect samen met X.

Ik heb nog steeds de vastlopers op het moment dat ik van X naar console of omgekeerd wissel. Is dat ook verholpen?
Met welke kernel versie heb je succes gehad

[Niek]

AlterEgo schreef op 23 April 2003 @ 21:01:
[...]


Ik heb nog steeds de vastlopers op het moment dat ik van X naar console of omgekeerd wissel. Is dat ook verholpen?
Met welke kernel versie heb je succes gehad

Hmm, vreemd. Ik draai hier de nieuwste development-sources (2.5.68) en XFree 4.3.0.
Ohja, ik draai versie 4349 van de nVidia drivers.

[voodooless]

Ik wilde net 2.5.68 proberen te compileren en kreeg de volgende foutmelding (heb bijna de zelfde .config gebruikt als voor mijn 2.5.66):

code:

  kernel/built-in.o  mm/built-in.o  fs/built-in.o  ipc/built-in.o  security/built-in.o  crypto/built-in.o  lib/lib.a  arch/i386/lib/lib.a  drivers/built-in.o  sound/built-in.o  arch/i386/pci/built-in.o  net/built-in.o --end-group  -o vmlinux
drivers/built-in.o(.text+0x11c4bd): In function `pcf_isa_waitforpin':
: undefined reference to `cli'
drivers/built-in.o(.text+0x11c4d8): In function `pcf_isa_waitforpin':
: undefined reference to `sti'
make: *** [vmlinux] Error 1

Weet iemand welke config-item de boosdoener is zodat ik dat eventueel uit kan zetten of hoe ik de fout kan oplossen?

Edit: Laat maar, ik heb het al gevonden, is een of andere I2C zooi die ik niet nodig had.

[ Voor 10% gewijzigd door voodooless op 23-04-2003 22:12 ]

[AlterEgo]

The_Surfer schreef op 23 April 2003 @ 21:11:
[...]

Hmm, vreemd. Ik draai hier de nieuwste development-sources (2.5.68) en XFree 4.3.0.
Ohja, ik draai versie 4349 van de nVidia drivers.

Ik heb het nogmaals geprobeerd met dezelfde config: op het moment dat ik van X naar console ga: hangen, en psychedelische kleuren op het scherm -> reset.
Zowel met Nvidia-AGP als met AGPART, met en zonder nvidia-openGL.
Tevens lukt het wisselen van resolutie niet met rivaFB: iedere resolutie die ik aan de kernel opgeef via lilo levert 640*480 op

[neographikal]

hij is in ieder geval een stuk sneller.

2.4.21pre7: via adaptec 2940 -> realtek een max van een kleine 2500KB/s op een P133 met een intelpro 100
Ik trek er nu al een dikke 3100 KB/s via de realtek die erin zit. Als ik em aan de Intel hang dan gaat tie probably nog harder (CPU staat op 100% bij deze snelheid nl. en die intel is wat zuiniger)

Niets dan lof tot nu toe, behalve dan die vga= die niet goed werkt

[Wirf]

Hier is nog een erg goed en up to date document dat over 2.5.x gaat:

http://www.codemonkey.org.uk/post-halloween-2.5.txt

[Verwijderd]

quote: neographikal

hmmja, maar als ik de vga=xxx spcificeer in de lilo.conf krijg ik nog steeds geen beeld op de console (ati mobility 9000). K heb de radeon driver geladen maar werken ho maar

Misschien een beetje vreemde vraag(van een linux noob) nl. Waarom gebruik je niet de ati driver(alleen 2d) of de DRI driver(met 3d support) of de officiele Ati drivers(ook met 3d support)? vga=xxx is voor framebuffer en moet je alleen gebruiken if all else fails.

[deadinspace]

Verwijderd schreef op 29 April 2003 @ 14:02:
Misschien een beetje vreemde vraag(van een linux noob) nl. Waarom gebruik je niet de ati driver(alleen 2d) of de DRI driver(met 3d support) of de officiele Ati drivers(ook met 3d support)? vga=xxx is voor framebuffer en moet je alleen gebruiken if all else fails.

Je kunt framebuffer gewoon gebruiken naast een fatsoenlijke XFree driver, om zo fatsoenlijk beeld op de console te hebben

[bkor]

2.5.69

announcement:

Ok,
I finally found the reason for why some of my machines had trouble with restarting the X server, and it turns out that it's been around since very early February. I bet others must have seen it too, with random crashes on X server restart when the server used AGP (which means that it mainly hit either hw-accelerated 3D setups or the intel integrated graphics which use a UMA model with AGP as the backing store).

That's a big relief for me, as it was the major thing I personally worried about for 2.6.x.

Anyway, that's fixed here, along with a lot of other updates. Much of 2.5.69 is small one-liners to drivers to handle the new IRQ semantics, but there's a lot of other cleanups in there too (Christoph Hellwig continued on his devfs rampage, for example).

NOTE! As of this release I think I'll want to have patches either be _really_ obvious, or they should go through one of more people for approval. In particular, I'm hoping that the paperwork stuff with Andrew should be getting closer to finalized, and that we could start moving over towards a 2.6.x release schedule..

Linus

Patch
Changelog
Source tarball

[Verwijderd]

<[e-mail]>
[PATCH] tty cleanups (1/12)

Christoph's fix for devfs problems with pty.

gelukkig


heeft lang geduurd deze keer, 10 dagen ofzo ?
maarja, morgen maar weer is testen

[rb338]

Eindelijk! Geen random X crashes meer...
Damn wat werd ik daar ziek van, constant een bevroren scherm

Maar dat is dus nu verholpen.. nou ik zal eens gaan kijken

[AlterEgo]

rb338 schreef op 05 May 2003 @ 12:19:
Eindelijk! Geen random X crashes meer...
Damn wat werd ik daar ziek van, constant een bevroren scherm

Maar dat is dus nu verholpen.. nou ik zal eens gaan kijken

Onder kernel 2.5.69 heb ik nog geregeld van die crashes (ook bij gebruik van VESA-FB en zonder render-accell) bij het wisselen van console.

Waaraan schrijf jij die random X crashes toe? Wisselen van tty / framebuffer ?
Ik snap je comment niet helemaal, geloof ik.

Ook is mijn framebuffer-bootup-tux verdwenen in 2.5.69 In 2.5.68 was ie er nog, en ik zie niets dat veranderd is in de config.

[ Voor 37% gewijzigd door AlterEgo op 05-05-2003 15:53 ]

[Verwijderd]

Is de 2.5.x kernel al klaar voor dagelijks gebruik of is ie daar nog te onstabiel voor?
Zo ja, wat voor extra programma's heb je nodig?(i.v.m. 2.4.20-8, bijv. die nieuwe modutils)

[neographikal]

Verwijderd schreef op 05 May 2003 @ 15:05:
Is de 2.5.x kernel al klaar voor dagelijks gebruik of is ie daar nog te onstabiel voor?
Zo ja, wat voor extra programma's heb je nodig?(i.v.m. 2.4.20-8, bijv. die nieuwe modutils)

Hier nog geen problemen ondervonden qua stabiliteitsproblemen. Ik durf hem bijna op me server in Amsterdam te zetten

[Verwijderd]

Verwijderd schreef op 05 May 2003 @ 15:05:
Is de 2.5.x kernel al klaar voor dagelijks gebruik of is ie daar nog te onstabiel voor?
Zo ja, wat voor extra programma's heb je nodig?(i.v.m. 2.4.20-8, bijv. die nieuwe modutils)

Als je de thread een beetje zou lezen zou je meerdere malen lezen dat je module-init-tools nodig heb (maar ik zie dat je dat al wist ). een posts terug staat nog een link naar dat post-haloween-2.5 verhaal, daar staat het zeker weten ook nog wel in.

2.5.68 was zeer stabiel voor mij (kernels ervoor ook wel)

Heb hem 11 dagen gedraait zonder X crashes, enige waar ik last van heb zijn SND_PCM_WAIT errors van xmms, weet niet zeker of die aan de kernel liggen maar heb ze sinds 2.5.65, zijn wel een stuk minder geworden met de nieuwste alsa-libs (van 4 mei geloof ik )


---
bah, nvidia-kernel 31xx doet het niet meer door die devfs cleanups in 2.5.69 (iets met devfs_(un)register ofzo bij het laden van de module
---
argh joy, heb blijkbaar toch nog devpts nodig want heb geen consoles in X.. en kan niet terug switchen met alt+Fn omdat ik sinds nvidia-kernel 4xxx dan een 'signal out of range krijg' (mja heb goeie syncs) en het is nog klote weer ook hoop geblaat dus

[ Voor 24% gewijzigd door Verwijderd op 05-05-2003 18:08 . Reden: niet goed gelezen waarop ik replyde :x ]

[neographikal]

Morgen gaat de .69 in me bak in Amsterdam draaien. Mijn ervaringen zijn tot nu toe goed en ook bij deze release is me bak een stuk sneller dan onder de 2.4.21rc1. Ben benieuwd morgen

[AlterEgo]

Ik heb eigenlijk iptables en iproute nodig. Maar die compileren niet met een 2.5 kernel.
Heeft iemand een alternatief? Binaries op een andere kernel gecompileerd = no go.

[neographikal]

iptables icm iproute weet ik niet maar iptables an sich gaat hier meer dan prima!

[AlterEgo]

Sorry, ik bedoel de userland tools van iptables. De modules draaien zonder probleem.

[rb338]

AlterEgo schreef op 05 mei 2003 @ 12:23:
[...]


Onder kernel 2.5.69 heb ik nog geregeld van die crashes (ook bij gebruik van VESA-FB en zonder render-accell) bij het wisselen van console.

Waaraan schrijf jij die random X crashes toe? Wisselen van tty / framebuffer ?
Ik snap je comment niet helemaal, geloof ik.

Ook is mijn framebuffer-bootup-tux verdwenen in 2.5.69 In 2.5.68 was ie er nog, en ik zie niets dat veranderd is in de config.

Met X bedoel ik gewoon XFree86, niks framebuffer. En aangezien ik dezelfde XFree86 gebruik op kernel 2.4 als op 2.5, wijt ik die crashes aan de kernel.

De crashes komen, zoals ik al zei, random. Dus niet bij het wisselen van tty's, want dan zou het niet random zijn, toch? Ik krijg dus spontaan bevroren schermen, wat ik ook doe (of zelfs als ik niks doe)

Als ik die comment van Linus goed begrijp is dat probleem dus opgelost.
Tenzij het aan de combinatie 2.5 kernel + nvidia drivers ligt...

-- edit:

Om mijn verhaaltje nog wat uit te breiden: Linus heeft het ook over X crashes bij een X-restart, daar heb ik ook last van. Maar dus ook van de random crashes, die ik hierboven al beschreef.

[ Voor 10% gewijzigd door rb338 op 06-05-2003 16:26 ]

[AlterEgo]

Nog een rare: in 2.5.69 zijn mijn CDrom-spelers verdwenen onder Vmware (Windows gast). Natief in 2.5.69 is er niets aan de hand; de /dev entires zijn er allemaal en werken prima.
Boot ik terug naar 2.5.68, dan zijn mijn CDspelers er weer onder Vmware

[neographikal]

Kernel hangt op dit moment in me server in amsterdam en hij is _snel_, ongelofelijk. Zelfs de pings zijn gedaald op me CS-servers tov de 2.4.21pre7 die er eerst inzat.

Wat mij betreft mag ie onderhand wel 2.6 worden genoemd.

[odysseus]

neographikal schreef op 06 May 2003 @ 21:59:
Wat mij betreft mag ie onderhand wel 2.6 worden genoemd.

Ik las net een bericht dat het had over 'eind volgende maand' als releasedatum van 2.6, maar ik moet zeggen dat ik dat wel heel snel zou vinden . Voordat 2.4 een keer kwam zijn er eerst ontwikkelkernels, testkernels en release candidates geweest. Je kunt 2.6 pas releasen als alle wijzigingen geweest zijn en er een tijdje gestabiliseerd is...zelf zou ik dan meer aan de zomer denken. Aan de andere kant zijn de berichten over de stabiliteit van 2.5 natuurlijk niet al te slecht en het zou toch een release zijn na anderhalf jaar, een respectabele tijd .

[deadinspace]

rb338 schreef op 06 May 2003 @ 16:23:
En aangezien ik dezelfde XFree86 gebruik op kernel 2.4 als op 2.5, wijt ik die crashes aan de kernel.

Het probleem is (afaik) al gelokaliseerd en gefixt, en het lag dus aan de kernel, maar zoiets hoeft niet meteen aan de kernel te liggen, ook al is dat de veranderde factor.

Bijvoorbeeld: Een dik halfjaar geleden kwam er een nieuwe versie van binutils uit. Met deze versie van binutils compilede de Linux kernel niet bij veel configuraties. Dus als je alleen je binutils upgrade dan kon je mogelijk de kernel die eerst altijd compilede niet meer compilen.

De oorzaak van dit alles was een bug in de kernelsource, niet in binutils. Deze bug had toevallig geen invloed op oudere versies van binutils, en wel op nieuwere. Zo kan 2.5 / 2.6 ook bugs in andere software aan het licht brengen (gcc3.x bijvoorbeeld... is niet ondenkbaar).

Zoiets hoeft dus niet persé de schuld te zijn van de veranderde factor, hou daar rekening mee

odysseus schreef op 06 May 2003 @ 22:05:
...en het zou toch een release zijn na anderhalf jaar, een respectabele tijd .

2.4 is uit Januari 2001... Dat maakt het 2½ jaar

[Verwijderd]

Lees de emails van Andrew Morton op linux-kernel@, 2.6.0 is nog lang niet af. Er zijn nog teveel dingen die nog niet af zijn of nog moeten worden geimplementeerd. Veel subsystems werken nu weer redelijk, maar met name de drivers lopen ver achter. Dat duurt echt nog minstens drie maanden voordat we aan 2.6-pre beginnen, en waarschijnlijk nog wel langer...

/me heeft net zijn patch opnieuw opgestuurd en heeft voor 't eerst reactie gekregen vanuit linux-kernel@, Gerd en Alan gaan d'r vanaf nu actief mee bezig. .

[Freak_NL]

Wat ik aan het typen was voor Phoenix/Firebird weer eens voor m'n ogen verdween*:

Hoe bouw je de Nvidia kernel module voor 2.5.69? Ik gebruik de 2.5 patch voor de 4363 serie (ben de link even kwijt), maar ik krijg nu ook devfs_unregister als missing symbol.. Mis ik iets in de kernel t.o.v. 2.5.68?

* Een stabiele browser met een werkende GTK2 scrollbar zou mooi zijn..

[Verwijderd]

galeon? epiphany? Werken allebei, en allebei Gtk2...

Moet je wel mozilla-1.3-gtk2 of mozilla-1.4 hebben. .

[Verwijderd]

Mijn Mozilla 1.4a met Epiphany 0.5 en ondersteuning voor Gtk2 geeft me een Windows achtige scrollbar..
_{(en de standaard afschuwelijke widgets in de pagina's zelf - zie bv een checkbox)}

[Freak_NL]

offtopic:
Ik gebruik nu nog Phoenix/Firebird uit de Mozilla CVS, maar Galeon trekt me meer eigenlijk. Het probleem zit in die rare scrollbalk, je kan via about:config wel die ngLayout key op native GTK2 scrollbar zetten, maar dan flipt die balk als je er mee scrolled! (heb daar last van op drie Gentoo machines, zal wel met een reden default uit staan)

Zijn er meer mensen die sinds een 2.5 kernel in gnome-terminal geen applicaties zoals menuconfig en alsamixer kunnen openen zonder die terminal te laten hangen? Ik doe al het zwaardere ncurses werk nu noodgedwongen in Eterm.

[Verwijderd]

Hm, ik heb net geprobeert om 2.5.69 te compilen, alleen doet ie het niet bij mij (ik zal vast iets verkeerd gedaan hebben). Dit heb ik gedaan:
make menuconfig
make dep -> toen kreeg ik: *** Warning: make dep is unnecessary now.
make bzImage
make modules
make modules_install -> dit werkte ook niet echt, dit kreeg ik te zien.

Ik heb met deze manier eerder m'n 2.4.20 kernel re-compiled, en dat werkte gewoon.
Ik run slackware 9.0 btw

[ Voor 12% gewijzigd door Verwijderd op 07-05-2003 12:41 ]

[odysseus]

Heb je wel de nieuwste modutils geïnstalleerd? Wat doet het precies niet - kun je niet booten?

[Verwijderd]

odysseus schreef op 07 May 2003 @ 12:47:
Heb je wel de nieuwste modutils geïnstalleerd? Wat doet het precies niet - kun je niet booten?

Ik heb modutils-2.4.22-i386-1
en hij blijft ook hangen bij het booten nadat hij het kernel heeft uncompressed.

edit:
Hmm.. volgens mij heb ik gewoon iets fout in m'n .config want m'n modules eindigen op .ko ipv .o?

[ Voor 21% gewijzigd door Verwijderd op 07-05-2003 12:59 ]

[Verwijderd]

Gaat het compilen van de modules wel helemaal goed?

[Verwijderd]

Verwijderd schreef op 07 May 2003 @ 13:03:
Gaat het compilen van de modules wel helemaal goed?

Yep, ik zie niets vreemd
Hier is m'n .config

[ Voor 17% gewijzigd door Verwijderd op 07-05-2003 13:45 ]

[Freak_NL]

make dep -> toen kreeg ik: *** Warning: make dep is unnecessary now.

Dat klopt. Geen make dep meer doen dus! (of wel als je nostalgisch aangelegd bent)

Ik heb modutils-2.4.22-i386-1

En module-init-tools? Die heb je ook nodig voor 2.5 kernelmodules!

Hmm.. volgens mij heb ik gewoon iets fout in m'n .config want m'n modules eindigen op .ko ipv .o?

Ik ook! Ow wacht, dat hoort zo..

[Verwijderd]

-edit- grrrrrr te laat... spuit-12 enzo...

[ Voor 91% gewijzigd door Verwijderd op 07-05-2003 14:21 ]

[Verwijderd]

Verwijderd schreef op 07 May 2003 @ 12:39:
make menuconfig
make dep -> toen kreeg ik: *** Warning: make dep is unnecessary now.
make bzImage
make modules
make modules_install -> dit werkte ook niet echt

Ik neem aan dat je hiervoor een:

make clean
make mrproper

hebt gedaan?

[Niek]

Freak_NL schreef op 07 May 2003 @ 09:51:
-snip-

Hoe bouw je de Nvidia kernel module voor 2.5.69? Ik gebruik de 2.5 patch voor de 4363 serie (ben de link even kwijt), maar ik krijg nu ook devfs_unregister als missing symbol.. Mis ik iets in de kernel t.o.v. 2.5.68?

-snip-

De patch die je nodig hebt staat hier: http://cvs.gentoo.org/cgi...rnel-1.0-4349-2.5.68.diff

[Freak_NL]

http://cvs.gentoo.org/cgi...rnel-1.0-4363-2.5.68.diff dan lijkt me?

Dank je, zal vanavond eens zien of dat helpt, maar als deze patch voor 2.5.68 ook al beschikbaar was, waarom krijg ik dan pas bij 2.5.69 de missing symbols?

[Freak_NL]

Deze site (minion.de) heeft een update voor hun 2.5 Nvidia-kernel-4363 patch voor de 2.5.69 kernel.

Morgen maar weer eens proberen of die patch werkt. (lijkt me wel, hun 2.5 patch werktte tot nu toe onder alle recente 2.5 kernels)

[rb338]

Ehm ik draai 2.5.69 op Gentoo (niet uit de ebuild, gewoon alles handmatig) en m'n nvidia drivers (ook 4363) werken perfect. Ik vraag me dus af wat ze bij minion.de hebben veranderd aan de 'oude' versie

[Freak_NL]

Draai je de Nvidia-kernel module uit portage of zelfgebouwd? Bij de Gentoo patch en Minion patch worden een aantal devfs gerelateerde zaken gefixed. (gvim die diffs maar eens)

De patch op minion.de doet nagenoeg hetzelfde als de Gentoo patch uit de recentere ebuilds, maar gooit er ook nog een Makefile.kbuild bij. (nieuwe stijl kernel module makefile)

Ik kreeg onder 2.5.68 de kernel module niet meer gecompileerd, dus ben ik deze patches gaan gebruiken. (portage liep net even achter)

[ Voor 3% gewijzigd door Freak_NL op 09-05-2003 11:52 ]

[rb338]

Uit portage
Steeds als ik een nieuwe kernel gebakken heb doe ik gewoon `emerge nvidia-kernel` en hop, 't werkt weer

[bkor]

2.5.70

announcement:

Ok,
there's been too much delay between 69 and 70, but I was hoping to make 70 the last "Linus only" release before getting together with Andrew and figuring out how to start the "pre-2.6" series and more of a code slush.

Whatever. The end result is a pretty big patch, although a lot of it is due to fairly minor patches. But it's a _lot_ of fairly minor patches, as can be seen from the changelog (also, the acorn drivers got moved around, which always makes for big patches).

Linus

Patch
Changelog
Source tarball

[Wirf]

Ik heb een poos geleden een patch voor lirc gekregen, zodat lirc ook onder 2.5.x werkt.
De patch is nog super-alfa en je kunt een aantal enge waarschuwingen te zien krijgen, maar het werkt (meestal) wel

De patch is tegen de CVS versie van 16 Mei, ik weet niet helemaal zeker of het nu nog werkt, de cvs server van lirc is een beetje brak ofzo

de patch is te downloaden van http://130.89.202.3/wander/lirc-patch.gz _{Zolang ik dit ip-addres heb}

[voodooless]

He Wirf, ik krijg deze patch niet uitgevoerd op mijn source. Heb je niet toevallig een tar.gz van jou hele gepatchte source tree staan die ik ergens zou kunnen downloaden. Ben al heel erg lang opzoek naar lirc voor 2.5.x maar heb nooit iets kunnen vinden. Waar heb je de patch trouwens vandaan?

[Wirf]

deepspace schreef op 06 June 2003 @ 11:17:
He Wirf, ik krijg deze patch niet uitgevoerd op mijn source. Heb je niet toevallig een tar.gz van jou hele gepatchte source tree staan die ik ergens zou kunnen downloaden.

http://130.89.202.3/wander/lirc-2.5.tar.bz2 alleen downloaden als je ook echt lirc op 2.5.x wil draaien, ik heb niet zoveel bandbreedte

Ben al heel erg lang opzoek naar lirc voor 2.5.x maar heb nooit iets kunnen vinden. Waar heb je de patch trouwens vandaan?

De patch heb ik van Manuel Estrada Sainz, die van mij weer een patch heeft gekregen die ik weer gebaseerd heb op code van Enrico Ros

Is open source niet geweldig?

[voodooless]

Thanks, nu de patch nog in de echte lirc tree krijgen

hmm, vage fout, iemand heeft hier een klok fout staan ofzo want ik grebruik npt:

code:

configure: error: newly created file is older than distributed files!

edit: heb de tijd al verzet met:

code:

find . -type f -exec touch {} \;

[ Voor 76% gewijzigd door voodooless op 06-06-2003 12:16 ]

[Wirf]

deepspace schreef op 06 June 2003 @ 11:47:
Thanks, nu de patch nog in de echte lirc tree krijgen

Once I get those ugly warnings gone, I post it to the list for peer
review. And send it to Christoph.

tja, of wachten dus, of zelf die warnings te lijf gaan

edit:

hmm, vage fout, iemand heeft hier een klok fout staan

oeps, mijn fout, op de een of andere manier denkt linux dat mn klok op UTC staat, zodat mijn klok een uur voorloopt

[ Voor 24% gewijzigd door Wirf op 06-06-2003 11:58 ]

[voodooless]

Compileren gaat nu goed, alleen krijg ik de kernelmodule lirc_serial niet ingeladen:

code:

modprobe lirc_serial
WARNING: Error inserting lirc_dev (/lib/modules/2.5.66/misc/lirc_dev.o): Unknown symbol in module, or unknown parameter (see dmesg)
FATAL: Error inserting lirc_serial (/lib/modules/2.5.66/misc/lirc_serial.o): Unknown symbol in module, or unknown parameter (see dmesg)

en dmesg:

code:

lirc_serial: no version magic, tainting kernel.
lirc_serial: Unknown symbol save_flags
lirc_serial: Unknown symbol cli
lirc_serial: Unknown symbol restore_flags
lirc_serial: Unknown symbol module_refcount
lirc_serial: Unknown symbol __module_get
lirc_serial: Unknown symbol lirc_register_plugin
lirc_serial: Unknown symbol lirc_unregister_plugin

Please help...

Edit: Oja, voor ik het vergeet: ik heb kernel 2.5.66 en de modules zijn ook tegen deze kernel gecompileerd. Module support staat aan...

[ Voor 9% gewijzigd door voodooless op 06-06-2003 13:21 ]

[Wirf]

deepspace schreef op 06 June 2003 @ 12:50:
Edit: Oja, voor ik het vergeet: ik heb kernel 2.5.66 en de modules zijn ook tegen deze kernel gecompileerd. Module support staat aan...

probeer eens een van de nieuwere kernels, volgens mij is deze module gemaakt voor 2.5.67 of 68

als dat ook niet werkt, tja, kan ik je ook niet verder helpen, vrees ik.

[voodooless]

Hmm, ben bezig met het compieren van kernel 2.5.70 maar deze schijnt een warning als een error aan te zien en stopt ermee. Weet iemand hoe ik dit kan voorkomen. Het stuk code is namelijk niet veranderd sinds 2.5.66, en die doet het perfect:

code:

drivers/scsi/aic7xxx/aic79xx_osm.c: In function `ahd_linux_map_seg':
drivers/scsi/aic7xxx/aic79xx_osm.c:776: warning: integer constant is too large for "long" type
make[3]: *** [drivers/scsi/aic7xxx/aic79xx_osm.o] Error 1
make[2]: *** [drivers/scsi/aic7xxx] Error 2
make[1]: *** [drivers/scsi] Error 2
make: *** [drivers] Error 2

Edit: al "opgelost", ik heb bij de Makefile in de aic7xxx dir "-Werror" bij de CFLAGS weggehaalt, en nu gaat ie door zonder te stoppen

Edit2: de Lirc driver werkt helaas ook niet samen met 2.5.70 (zelfde error), back to the drawingboard I fear

[ Voor 24% gewijzigd door voodooless op 10-06-2003 10:30 ]

[Cyril]

Okee, 2.5.71 is er...

announcement:

I think I'll call this kernel the "sticky turtle", in honor of that
historic "greased weasel" kernel, and as a comment on how sadly dependent
I've become on the daily BK snapshots. It's been too long since 2.5.70.

I'll do better, I promise. While most developers happily use either the
daily snapshots or the BK tree itself, not everybody does, and a lot of
users want "real releases".

There's nothing hugely interesting here, but Al Viro ha sbeen cleaning up
the tty layer, and Stephen Hemminger has been fixing up some network
device alloc/free issues with the help of various people.

And obviously there are the normal usb/pcmcia/sound/architecture updates.
With driver models and networking thrown in as a bonus.

Linus

Patch
Changelog
Source tarball

[Leon]

Als hij niet compiled moet je dit berichtje maar eens lezen: 2.5.71 fails compile (net/built-in.o)

en deze patch toepassen op linux/net/core/flow.c

code:

--- flow.old    2003-06-14 18:17:35.000000000 -0400
+++ flow.c      2003-06-14 18:13:03.000000000 -0400
@@ -5,6 +5,7 @@
   */

  #include <linux/kernel.h>
+#include <linux/cpu.h>
  #include <linux/list.h>
  #include <linux/jhash.h>
  #include <linux/interrupt.h>

(alleen een include toevoegen dus)

[Cyril]

2.5.72 met een belangrijke aankondiging van Linus...

announcement:

Ok, I waited too long for 2.5.71, so here's a more timely 2.5.72
release.

It's extra timely largely because the hash list poisoning found some
problems in the RPC code, making NFS break. Trond found and fixed the
breakage, so 2.5.72 should work fine in an NFS environment too. Let's
see if the list poisoning shows any other dodgy list users. Knock wood.

Also, Arnaldo has cleaned up a lot of the networking code to use the
generic hash lists, instead of the old ad-hoc net-specific list walking
code. That code has been tested pretty well, but please holler if you
see something.

Changelog for other details appended.

The other big news - well, for me personally, anyway - is that I've
decided to take a leave-of-absense after 6+ years at Transmeta to
actually work full-time on the kernel.

Transmeta has always been very good at letting me spend even an
inordinate amount of time on Linux, but as a result I've been feeling a
little guilty at just how little "real work" I got done lately. To fix
that, I'll instead be working at OSDL, finally actually doing Linux as
my main job.

[ I do not expect a huge amount of change as a result, testament to just
/how/ freely Transmeta has let me do Linux work. My email address will
change to "[e-mail]" effective July 1st, but everybody is
trying to make the transfer as smooth as possible, so we'll make sure
that there will be sufficient address overlap etc to not cause any
problems ]

OSDL and Transmeta will have a joint official (read: "boring". You
should have seen the bio - that didn't make it - that I suggested for
myself for it press-release about this tomorrow morning, but I just
wanted to say thanks to Transmeta. It has been a special place to work
for, and hello to OSDL that I hope will be the same.

Snif. I'm actually all teary-eyed.


Linus

Patch
Changelog
Source tarball