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

[sebas]

Ik heb het een aantal keren (8?) geprobeerd, en telkens in de config bij framebuffer iets aangepast, het lijkt erop dat de framebuffer console driver niet wil compileren aan het eind, dezelfde error kreeg ik trouwens ook met 2.5.63, die heb ik ook even getest.

Wel of niet schone dir maakte ook niets uit. Wel dus het niet meebakken van de framebuffer, maar op een notebook heb je er vrij weinig aan als de console framebuffer het niet doet. De zo gecompileerde kernel bootte schijnbaar wel door, echter zonder beeld. Alles bleef zwart, een aantal andere combinaties compileerden niet eens.

What to do?

[Verwijderd]

heb je wel standaard VGA console support (non-fb) meegecompileerd? Anders zie je idd. niks. .

[sebas]

Jawel, die, de VESA drivers en de radeon drivers, en dat gaat dus mis. Ik heb het nog een keer op de traditionele manier geprobeerd om de kernel te maken, maar ook hier krijg ik de error (bij make bzImage). Als ik een kernel start die het doet blijft het dus zwart en ik krijg de volgende dingen in me messages te staan:

Mar 11 03:49:32 neo syslogd 1.4.1#10: restart.
Mar 11 03:49:33 neo kernel: klogd 1.4.1#10, log source = /proc/kmsg started.
Mar 11 03:49:33 neo kernel: Inspecting /boot/System.map-2.5.64
Mar 11 03:49:33 neo kernel: Loaded 24051 symbols from /boot/System.map-2.5.64.
Mar 11 03:49:33 neo kernel: Symbols match kernel version 2.5.64.
Mar 11 03:49:33 neo kernel: No module symbols loaded - kernel modules not enabled.
Mar 11 03:49:33 neo kernel: Linux version 2.5.64 (root@neo) (gcc version 3.2.1 20020924 (Debian prerelease)) #1 Tue Mar 11 03:40:38 CET 2003
Mar 11 03:49:33 neo kernel: Video mode to be used for restore is 317
Mar 11 03:49:33 neo kernel: BIOS-provided physical RAM map:
Mar 11 03:49:33 neo kernel: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
Mar 11 03:49:33 neo kernel: BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
Mar 11 03:49:33 neo kernel: BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
Mar 11 03:49:33 neo kernel: BIOS-e820: 0000000000100000 - 000000001fff9000 (usable)
Mar 11 03:49:33 neo kernel: BIOS-e820: 000000001fff9000 - 000000001ffff000 (ACPI data)
Mar 11 03:49:33 neo kernel: BIOS-e820: 000000001ffff000 - 0000000020000000 (ACPI NVS)
Mar 11 03:49:33 neo kernel: BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
Mar 11 03:49:33 neo kernel: 0MB HIGHMEM available.
Mar 11 03:49:33 neo kernel: 511MB LOWMEM available.
Mar 11 03:49:33 neo kernel: On node 0 totalpages: 131065
Mar 11 03:49:33 neo kernel: DMA zone: 4096 pages, LIFO batch:1
Mar 11 03:49:33 neo kernel: Normal zone: 126969 pages, LIFO batch:16
Mar 11 03:49:33 neo kernel: HighMem zone: 0 pages, LIFO batch:1
Mar 11 03:49:33 neo kernel: ACPI: RSDP (v000 ASUS ) @ 0x000f6870
Mar 11 03:49:33 neo kernel: ACPI: RSDT (v001 ASUS P4_L3CS 16944.11825) @ 0x1fff9000
Mar 11 03:49:33 neo kernel: ACPI: FADT (v001 ASUS P4_L3CS 16944.11825) @ 0x1fff9080
Mar 11 03:49:33 neo kernel: ACPI: BOOT (v001 ASUS P4_L3CS 16944.11825) @ 0x1fff9040
Mar 11 03:49:33 neo kernel: ACPI: DSDT (v001 ASUS P4_L3CS 00000.04096) @ 0x00000000
Mar 11 03:49:33 neo kernel: ACPI: BIOS passes blacklist
Mar 11 03:49:33 neo kernel: ACPI: MADT not present
Mar 11 03:49:33 neo kernel: Building zonelist for node : 0
Mar 11 03:49:33 neo kernel: Kernel command line: root=/dev/hda1 ro hdc=ide-scsi vga=791 resume=/dev/hda2
Mar 11 03:49:33 neo kernel: ide_setup: hdc=ide-scsi
Mar 11 03:49:33 neo kernel: No local APIC present or hardware disabled
Mar 11 03:49:33 neo kernel: Initializing CPU#0
Mar 11 03:49:33 neo kernel: PID hash table entries: 2048 (order 11: 16384 bytes)
Mar 11 03:49:33 neo kernel: Detected 1799.622 MHz processor.
Mar 11 03:49:33 neo kernel: Calibrating delay loop... 3547.13 BogoMIPS
Mar 11 03:49:33 neo kernel: Memory: 515024k/524260k available (2115k kernel code, 8452k reserved, 698k data, 148k init, 0k highmem)
Mar 11 03:49:33 neo kernel: Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Mar 11 03:49:33 neo kernel: Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Mar 11 03:49:33 neo kernel: Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
Mar 11 03:49:33 neo kernel: Failed to register 'sysfs' in sysfs
Mar 11 03:49:33 neo kernel: -> /dev
Mar 11 03:49:33 neo kernel: -> /dev/console
Mar 11 03:49:33 neo kernel: -> /root
Mar 11 03:49:33 neo kernel: CPU: Trace cache: 12K uops, L1 D cache: 8K
Mar 11 03:49:33 neo kernel: CPU: L2 cache: 512K
...

[Verwijderd]

sebas schreef op 12 March 2003 @ 13:31:
Jawel, die, de VESA drivers en de radeon drivers

Neenee, niet de fb. Character devices -> virtual terminal et all, dus de standaard console support voor non-fb.

En heb je wel vga=XXX uit je lilo/grub configuratie gehaald? (just checking). .

[edit]
Oh trouwens, modules uit? Waar ben jij mee bezig? Of heb je nog oude modutils rondhangen?

[ Voor 14% gewijzigd door Verwijderd op 12-03-2003 16:55 ]

[sebas]

Ik heb vga=791 nog in me menu.list van grub staan, ik zal zo even kijken of die zonder vga opties wel goed opstart. Ik heb /lib/modules/2.5.64/ netjes gerenamed om er zeker van te zijn dat hij wel de nieuwe goede modules pakt.

Wat ik echter raar vind zijn de errors bij het compileren. Ok, het is dan een development kernel, maar dat ik de configuratie met framebuffer support niet mee kan compileren ... ?


De config die dus niet wil compileren kun je hier vinden

\edit

als ik de vga opties weglaat, komt hij tot
"Ok, booting the kernel.", daarna doet die nog wel wat, is aan onregelmatige diskactiviteit te zien, maar er gebeurt vervolgens niets meer.

Ik kan trouwens bij Character Devices geen console vinden, die staan volgens mij nu bij Graphics. Zoals je in de config kunt zien zouden ze aan moeten staan. Ik heb in het begin gewoon de config van mijn 2.4.20 gepakt, alles doorgelopen en deze gebakken, resultaat dus: of zwart scherm, geen output meer na het laden van de kernel (net gebeurt) of errors bij het compilen waardoor het kernel image niet gemaakt wordt.

[ Voor 38% gewijzigd door sebas op 12-03-2003 19:24 ]

[blouweKip]

Zow, ik heb net ff 2.5.64 gemaakt (wacht met smart op de verbeteringen in 2.5.65)

emerge moduleinit-tools development-sources in gentoo

Kernel draait prima, nvidia kernel laad ook prima en X e.d voelt al een stuk sneller

Eindelijk ook alsa er in

* blouweKip heeft goede hoop voor 2.6)

[Verwijderd]

sebas schreef op 12 March 2003 @ 19:11:
Wat ik echter raar vind zijn de errors bij het compileren. Ok, het is dan een development kernel, maar dat ik de configuratie met framebuffer support niet mee kan compileren ... ?

Development...

fb is gewoon nog niet af in 2.6.x, het is een nieuwe interface en sommige drivers moeten nog geport worden...

[sebas]

Ah, naja. Dan ga ik gewoon lekker verder 2.4.20 gebruiken, en wacht nog even tot ik de wondere wereld van linux 2.6 mag genieten. Ik wist niet dat de framebuffer dingen nog niet af zijn, maar inderdaad, het is een development thingie ...

Wel heel veel kewle nieuwe features die er in de nieuwe branche zitten. Linux 2.6 gaat roeleren

thx in elk geval voor het meekijken

[Erhnam]

Verwijderd schreef op 12 maart 2003 @ 21:30:
[...]


Development...

fb is gewoon nog niet af in 2.6.x, het is een nieuwe interface en sommige drivers moeten nog geport worden...

Kan iemand mij wat vertellen wat er voor leuks te wachten staat ? Wordt dit de desktop dream comes true kernel? Met leuke ondersteuning voor videokaarten en sound (ALSA) ?

Ik zit nog steeds te wachten op de eerste mac-os-x-look-like desktop maar dan onder linux

[sebas]

Je kunt uiteraard al een kijkje nemen in de opties, gewoon even een development kernel downloaden en in menuconfig o.i.d. kijken, zeer veel nieuwe stoere features, zoals inderdaad alsa, verbeterde acpi support, softwaresuspend, ....

[deadinspace]

Erhnam schreef op 13 maart 2003 @ 12:29:
Kan iemand mij wat vertellen wat er voor leuks te wachten staat ?

Nieuwe I/O scheduler, nieuwe process scheduler, verbeterde interactiviteit en lagere kernel-latencies (zie ook http://www.kerneltrap.org/node.php?id=603), standaard ALSA, verbeterde hardware support (Firewire niet meer experimental, dat soort dingen), volgensmij ook een verbeterde framebuffer...

Wordt dit de desktop dream comes true kernel?

Nouja, je kunt ook op teveel hopen
Maar 2.6 belooft iig wel leuk te worden op de desktop.

Ik zit nog steeds te wachten op de eerste mac-os-x-look-like desktop maar dan onder linux

Die zijn er al hoor... Dat wil zeggen, je kunt met bepaalde themes KDE of Enlightenment héél erg erop laten lijken.

En bovendien is dat geen kernel issue, en ook nooit geweest

[Erhnam]

deadinspace schreef op 13 maart 2003 @ 14:09:
[...]

Nieuwe I/O scheduler, nieuwe process scheduler, verbeterde interactiviteit en lagere kernel-latencies (zie ook http://www.kerneltrap.org/node.php?id=603), standaard ALSA, verbeterde hardware support (Firewire niet meer experimental, dat soort dingen), volgensmij ook een verbeterde framebuffer...

[...]

Nouja, je kunt ook op teveel hopen
Maar 2.6 belooft iig wel leuk te worden op de desktop.

[...]

Die zijn er al hoor... Dat wil zeggen, je kunt met bepaalde themes KDE of Enlightenment héél erg erop laten lijken.

En bovendien is dat geen kernel issue, en ook nooit geweest

Wat ik het geile vind van osx is niet zo zeer hoe het er uit ziet (ja die dock onderin is vet) maar hoe de zooi mbv opengl op je scherm geredenderd wordt. Vensters die naar beneden glijen en iconen die opspringen in de dock maken osx echt een lust voor het oog.
Hier kan geen windowmaker aan tippen (misschien ooit, in de toekomst, enlightement met directfb of fresco support)

Ik denk als Linus en de rest van de communitie willen dat linux echt een keer doorbreekt zouden misschien betere standaarden moeten opstellen. (en om te beginnen de desktop er lekker slick uit te laten zien)

Betere drivers en ondersteuning waarbij dit soort dingen mogelijkworden. Het is natuurlijk een probleem wat te maken heeft met de desktop developers (zoals gnome en kde) en de driver producten, wat zoals je zegt losstaat en geen kernel issue is maar misschien zou Linus toch het voortouw moeten nemen in het opstellen van een standaard (misschien zoals dat met ALSA gebeurd)

Een goede standaard zou er voor zorgen dat desktop developers en misschien spelproducenten zich meer aangetrokken voelen tot Linux (en dan opengl als standaard) want nu wijken ze allemaal uit naar DirectX wat een doorbraak nog moeilijker maakt.

[ Voor 11% gewijzigd door Erhnam op 13-03-2003 14:27 ]

[blouweKip]

Ik denk als Linus en de rest van de communitie willen dat linux echt een keer doorbreekt zouden misschien betere standaarden moeten opstellen. (en om te beginnen de desktop er lekker slick uit te laten zien)

Daar heeft linus weinig mee van doen, bovendien zijn er al "standaarden", wat jij bedoeld is da er 1 desktop environment is...dat zal iig nooit zover komen

Betere drivers en ondersteuning waarbij dit soort dingen mogelijkworden. Het is natuurlijk een probleem wat te maken heeft met de desktop developers (zoals gnome en kde) en de driver producten, wat zoals je zegt losstaat en geen kernel issue is maar misschien zou Linus toch het voortouw moeten nemen in het opstellen van een standaard (misschien zoals dat met ALSA gebeurd)

Tja, driver blijven natuurlijk primair de verantwoordelijkheid van de hardwareboer, windows en mac zijn niet zo gebruiksvriendelijk door resp MS/apple maar doordat de hardwareboertjes er drivers voor maken (idem voor software)

Een goede standaard zou er voor zorgen dat desktop developers en misschien spelproducenten zich meer aangetrokken voelen tot Linux (en dan opengl als standaard) want nu wijken ze allemaal uit naar DirectX wat een doorbraak nog moeilijker maakt.

Een goede standaard voor wat?
OpenGL is al de defacto 3d standaard op linux, dat spelfabrikanten gebruik maken van directx heeft alles met luiheid en kortzichtigheid te maken, niet met het ontbreken van een goede platform afhankelijke api

Dingen die iig de desktop wel zullen verbeteren: evas, xfree 5, fresco (en directfb zodra nvidia meer informatie geeft zodat er hw fb support komt voor hun kaarten die ook daadwerkelijk werkt)

[Verwijderd]

deadinspace schreef op 13 March 2003 @ 14:09:
Nieuwe I/O scheduler, nieuwe process scheduler, verbeterde interactiviteit en lagere kernel-latencies (zie ook http://www.kerneltrap.org/node.php?id=603), standaard ALSA, verbeterde hardware support (Firewire niet meer experimental, dat soort dingen), volgensmij ook een verbeterde framebuffer...

Je mist de threading (NPTL) nog. . En daarnaast video4linux2.

In het kort: 2.6.x gaat roeleren, maar de verbeteringen zijn met name scalability verbeteringen, dus op grote megaservers en mainframes enzo. Op de desktop merk je er wel iets van, maar dat was niet de eerste doelstelling van bovenstaande veranderingen (a la scheduler, threading, etc.).

Erhnam schreef op 13 March 2003 @ 14:25:
Ik denk als Linus en de rest van de communitie willen dat linux echt een keer doorbreekt zouden misschien betere standaarden moeten opstellen. (en om te beginnen de desktop er lekker slick uit te laten zien)

Wat hebben desktop, standaarden en kernel drivers met elkaar te maken? .

De desktop is al slick. Nog niet zo als Aqua, maar daar zit dan ook een vol team 24/7 aan te programmeren, Gnome en KDE hebben gewoon minder developers. Als je dat wil, dan moet je zorgen dat er een groot desktopteam KDE en/of Gnome gaat enhancen. Momenteel is dat nog niet echt realiteit.

De standaarden zijn er al lang, er is alleen nog niemand op het idee gekomen (of heeft de tijd gehad om het te implementeren) om openGL WMs te maken...

Betere drivers en ondersteuning waarbij dit soort dingen mogelijkworden. Het is natuurlijk een probleem wat te maken heeft met de desktop developers (zoals gnome en kde) en de driver producten, wat zoals je zegt losstaat en geen kernel issue is maar misschien zou Linus toch het voortouw moeten nemen in het opstellen van een standaard (misschien zoals dat met ALSA gebeurd)

.

Linus heeft geen reet met ALSA te maken, Linus gooit het in de kernel, voor de rest doet hij niks daaraan. Hij houdt zich alleen met core kernel zaken (scheduler, task list, e.d.) bezig, en zelfs dan voornamelijk met manager-achtig werk, qua coden doet hij een stuk minder dan je zou denken. Drivers doen anderen, interfaces hiervoor ook. ALSA wordt geleid door het ALSA development team, bv.

Drivers zijn een onderdeel van de kernel, de implementaties van de eigenlijke interfaces (APIs), gemaakt door programmeurs die toevallig hardwareondersteuning nodig hadden. Voor zaken als 3D bestaan drivers (en dus interfaces), dus ik zie niet waarom dit de ontwikkeling van de desktop zou afremmen...

Nogmaals, dit is met name een zaak van tijdgebrek. Als iemand opeens een team van 100 desktop devvers een jaar lang op KDE en/of Gnome zet, dan komt er ongetwijfeld iets heel moois uit, maar niemand heeft dat tot nu toe gedaan... Dat heeft niks met kernel en drivers te maken.

[Verwijderd]

Laat ze eerst maar eens 100 man op XFree zetten en binnen 6 maanden XFree 5.0 in elkaar zetten..

[blouweKip]

of op alsa..
zelfs met die oss-compatibility zut werkt de helft van mn geluid nog steeds niet (* blouweKip gaat bij de volgende dev kernel weer naar oss)

[Verwijderd]

ALSA zuigt, dat roep ik nou al jaren, wanneer luisteren jullie eens? .

X, tjsa... krijgen we die discussie weer? X is een standaard, laten we blij zijn dat we eens een standaard hebben (die nog redelijk werkt ook) in plaats van continue weer te zeuren dat het niet snel genoeg is...

[AlterEgo]

Ik zou het bijna posten in het linux-humor draadje:

hdparm -Tt /dev/hda

/dev/hda:
Timing buffer-cache reads: -3008 MB in 0.00 seconds = -inf kB/sec
Timing buffered disk reads: -1504 MB in 0.00 seconds = -inf kB/sec
Hmm.. suspicious results: probably not enough free memory for a proper test.

errug suspicious
kernel 2.5.64. Dmesg laat niets geks zien qua IDE herkenning; hdparm /dev/hda ook niet. Suggesties

[Verwijderd]

Verwijderd schreef op 13 March 2003 @ 15:46:
X, tjsa... krijgen we die discussie weer? X is een standaard, laten we blij zijn dat we eens een standaard hebben (die nog redelijk werkt ook) in plaats van continue weer te zeuren dat het niet snel genoeg is...

Ik vind niet alleen dat het niet snel genoeg is, ik heb gewoon het idee dat X een 'dooie standaard' is geworden en de afgelopen jaren erg is verwaarloosd..
_{(en er is veel meer dan alleen maar de snelheid wat sterk verbeterd kan worden)}

En moet je eens zien hoe 'veel' mensen er nou aan X werken..
Zo'n project zou veel en veel meer (actieve) ontwikkelaars moeten hebben.

Hoeveel mensen werken er nou in totaal aan dat nieuwe render model.. (XRender + Xc/Xr libs en nog wat afaik)
2 mensen? (Keith Packard, Carl Worth, .. ?)
_{(al ben ik wel blij te zien dat XRender van v0.2 (vorig jaar) omhoog is gegaan naar v0.6 oid in XFree 4.3)}

En van die 2 (Keith Packard) werkt dan ook nog eens aan vele andere dingen (eg. Fontconfig) en dus niet fulltime aan XRender..

Maar goed, dit topic ging over linux 2.5 .. binnenkort hebben we dus een geweldige kernel en verslonsde grafische server wegens tekort aan mankracht.
_{(al is het allemaal de stomme schuld van de mensen achter XFree.. bijna iedere patch die binnenkomt wordt doorgestuurd naar /dev/null)}

[deadinspace]

Erhnam schreef op 13 March 2003 @ 14:25:
Wat ik het geile vind van osx is niet zo zeer hoe het er uit ziet (ja die dock onderin is vet) maar hoe de zooi mbv opengl op je scherm geredenderd wordt. Vensters die naar beneden glijen en iconen die opspringen in de dock maken osx echt een lust voor het oog.

Laat ik beginnen met het volgende: Smaken verschillen. Ik vind het walgelijk.

En verder heeft dit nog steeds niks met de kernel te maken.

Hier kan geen windowmaker aan tippen (misschien ooit, in de toekomst, enlightement met directfb of fresco support)

Het is "windowmanager", en directfb en/of fresco gaan je waarschijnlijk weinig helpen.

Ik denk als Linus en de rest van de communitie willen dat linux echt een keer doorbreekt

Linus heeft daar helemaal geen behoefte aan. Hij wil gewoon wat gaafs in elkaar zetten. En gelijk heeftie.

zouden misschien betere standaarden moeten opstellen. (en om te beginnen de desktop er lekker slick uit te laten zien)

Like what? Er zijn standaarden zat.

Een goede standaard zou er voor zorgen dat desktop developers en misschien spelproducenten zich meer aangetrokken voelen tot Linux (en dan opengl als standaard) want nu wijken ze allemaal uit naar DirectX wat een doorbraak nog moeilijker maakt.

En OpenGL - een standaard - is er nu zeker niet dan?
Ik bedoel - wat is je probleem nou helemaal?

Verwijderd schreef op 13 maart 2003 @ 15:10:
Je mist de threading (NPTL) nog. . En daarnaast video4linux2.

Ik mis wel meer, ik kan onmogelijk alle veranderingen van 2.4 -> 2.6 opnoemen

Maar NPTL is idd ook wel een belangrijke verbetering. v4l2 heb ikzelf niet zoveel aan, aangezien ik dat soort spul niet gebruik (komt nog wel als ik een TVkaart koop), maar das voor jou natuurlijk anders

In het kort: 2.6.x gaat roeleren, maar de verbeteringen zijn met name scalability verbeteringen, dus op grote megaservers en mainframes enzo. Op de desktop merk je er wel iets van, maar dat was niet de eerste doelstelling van bovenstaande veranderingen (a la scheduler, threading, etc.).

Ja, maar ik verwacht wel het een en ander van die veranderingen voor de desktop... Zo is die nieuwe I/O scheduler sowieso een verbetering, ook op de desktop. En de nieuwe process scheduler legt meer nadruk op fairness (belangrijk op een desktop), en verbetert dus als het goed is de interactiviteit/latency (ook belangrijk op een desktop).

Het zijn idd geen veranderingen (op die interactivitie dingen na dan) die met de desktop als overweging zijn gemaakt, maar ze zullen wel zo hun invloed erop hebben.

Verwijderd schreef op 13 March 2003 @ 15:21:
Laat ze eerst maar eens 100 man op XFree zetten en binnen 6 maanden XFree 5.0 in elkaar zetten..

Start coding; Zeuren kan iedereen

En ja, het XFree team moet zich wat opener opstellen, maar dat is de laatste tijd ook aan het gebeuren.

Verder ga ik niet al te veel woorden meer aan vuilmaken hieraan, maar ik wil wel nog even opmerken dat X != XFree86. Haal het protocol en de implementatie niet door elkaar.

AlterEgo schreef op 13 March 2003 @ 15:56:
Ik zou het bijna posten in het linux-humor draadje:

[...]

errug suspicious
kernel 2.5.64. Dmesg laat niets geks zien qua IDE herkenning; hdparm /dev/hda ook niet. Suggesties

Hmm, hij test met -23.5 keer zoveel data als normaal Weird.
Doet hdparm het met een 2.4 kernel wel goed? Levert een strace iets op?

[Verwijderd]

deadinspace schreef op 13 March 2003 @ 17:15:
Start coding; Zeuren kan iedereen

1. mijn interesses liggen in een heel ander gebied en ik zou dan eerst tijd moeten besteden aan research voor iets wat me niet interresseert, dat gaat niet werken (als het niet betaald iig)
2. ik heb niet genoeg ruimte op m'n HD over om minimaal 2 cvs versies van XFree op te plaatsen (wat voor mij een vereiste is wanneer ik aan een groot programma werk (1 cvsversie + 1 werkversie, zodat er niets fout kan gaan tijdens het updaten/mergen)
3. als ik op iedere 'start coding' boodschap was ingegaan die ik tot nu toe tegen m'n kop gesmeten heb gekregen zou ik nu zo'n 395 uur per dag nodig hebben om ook daadwerkelijk te helpen met al die projecten
4. ik vind het leuk om per dag minimaal een paar uur het spel 'Real Life' te spelen

Verder ga ik niet al te veel woorden meer aan vuilmaken hieraan, maar ik wil wel nog even opmerken dat X != XFree86. Haal het protocol en de implementatie niet door elkaar.

Weet ik, maar 'X' is minder typewerk

..ontopic maar weer

[Verwijderd]

Verwijderd schreef op 13 maart 2003 @ 16:32:
Ik vind niet alleen dat het niet snel genoeg is, ik heb gewoon het idee dat X een 'dooie standaard' is geworden en de afgelopen jaren erg is verwaarloosd..

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

_{(en er is veel meer dan alleen maar de snelheid wat sterk verbeterd kan worden)}

Like? .

XFree doet alle soorten acceleraties die er zijn, maar omdat de interface en structuur wat moeilijk lijkt vinden mensen het kut. Heb je nou al eens werkelijk tests gedaan of het sneller zou worden als je een directe local-only blabla windows-achtige GUI bouwt? Wordt het sneller? Ligt dat aan X?

Een van de manieren om dit sneller te maken is directfb, maar dat is geen optie voor een X server. Directfb zou een X extensie kunnen zijn, maar voor de rest kan X zoveel meer... Die tiende van een duizendste van een seconde kan mij dan echt geen ruk schelen...

[AlterEgo]

deadinspace schreef op 13 March 2003 @ 17:15:
[...]
Hmm, hij test met -23.5 keer zoveel data als normaal Weird.
Doet hdparm het met een 2.4 kernel wel goed? Levert een strace iets op?

Gevonden: het is een bugje in hdparm-5.3 (gentoo). 5.2 Doet het normaal.

[wzzrd]

Foutje in Makefile van 2.5.64?

code:

arch/i386/boot/setup.S: Assembler messages:
arch/i386/boot/setup.S:165: Warning: value 0x37ffffff truncated to 0x37ffffff
  ld -m elf_i386  -Ttext 0x0 -s --oformat binary -e begtext arch/i386/boot/setup.o -o arch/i386/boot/setup
make -f scripts/Makefile.build obj=arch/i386/boot/compressed \
                                IMAGE_OFFSET=0x100000 arch/i386/boot/compressed/vmlinux
make[2]: *** No rule to make target `vmlinux', needed by `arch/i386/boot/compressed/vmlinux.bin'.  Stop.
make[1]: *** [arch/i386/boot/compressed/vmlinux] Error 2
make: *** [bzImage] Error 2

[Cyril]

2.5.65, deze bevat dus o.a. de nieuwe Linus/Ingo Molnar scheduler..

announcement:

I've delayed this too long, but Ingo found why the scheduler sometimes did
bad things, and this should all be good.

A lot of fairly small changes all over the map, see the full changelog for
details.

Linus

Patch
Changelog
Source tarball

[Verwijderd]

O(1) dood? .

Of wat voor scheduler? /me snapt 't ff niet...

[Verwijderd]

Verwijderd schreef op 18 maart 2003 @ 07:45:
O(1) dood? .

Of wat voor scheduler? /me snapt 't ff niet...

Huh ? wat ist ? en hoe ist met die labrat ?

[Cyril]

euhm, ik bedoelde dus dit geval..

[Verwijderd]

Hoe krijgen jullie die nvidia driver aan de praat? Ik heb net 2.5.64 geinstalleerd en het lijkt goed te werken. Ik krijg alleen de nvidia driver niet aan de praat op mn slackware 9.0-beta box. Ik heb de nieuwste sources gedownload van het xfree86-nvidia project NVIDIA_kernel-1.0-4191.tar.gz en bijbehorende GLX source. De melding is "this driver does not support 2.5.x development kernels". Ok kan ik me iets bij voorstellen. Zijn er ergens drivers te vinden die 2.5.x wel ondersteunen? Als ik dit draadje zo wat doorlees zijn er schijnbaar mensen die dit gewoon draaiend hebben.

[Wirf]

Weet iemand hoe je Lirc aan de gang krijgt met 2.5? dat is nog het enige wat bij mij nog niet werkt

[wzzrd]

smasr: waarschijnlijk gebruiken die mensen de nv driver in XFree86 en niet de nvidia driver. Dat ding wordt niet verspreid in source vorm, maar in een soort halve binary, zodat je hem alleen nog hoeft te linken (en de source niet kunt zien). Zover ik weet is er buiten de nv driver voor XFree86 geen werkende nvidia driver onder kernel 2.5.x

Wirf: lirc wordt gebouwd tegen je huidige kernel. De huidige versies zijn afgestemd op de 2.4.x serie. Bouwen tegen de development sources gaat denk ik gewoon niet lukken. Er staat in de mailinglist een post van iemand van rond 25 februari j.l. die iets vraagt zoals jij, maar ik geloof niet dat hij al antwoord heeft gekregen...

[Sjonny]

geen idee of het werkt maar je kan deze patch voor nvidia proberen:
http://www.minion.de/nvidia.html

[Verwijderd]

wzzrd schreef op 18 March 2003 @ 13:04:
smasr: waarschijnlijk gebruiken die mensen de nv driver in XFree86 en niet de nvidia driver... <snip>

Ja ik was er ook net achter. Ik kon alleen een vage nvidia patch vinden bedoeld voor een pre 2.5.x kernel. Nou ja ik heb nu de nv driver geactiveeerd en het werkt. Jammer van mn Quake3 sessies dan de komende tijd Nou ja

Bedankt voor je info. Ik ga nu ff Mozilla 1.3 installeren en wat testen met de desktop. Het voelt allemaal al een tikkie sneller met 2.5.64 inclusief die Linus/Ingo patch. Vooral de muis wijzer blijft lekker soepel functioneren terwijl je van allerlei programma's ondertussen aan het starten bent. Voor de rest nog geen schokkende veranderingen gezien maar ik moet nog ff wat testen.

[Verwijderd]

Sjonny schreef op 18 maart 2003 @ 13:11:
geen idee of het werkt maar je kan deze patch voor nvidia proberen:
http://www.minion.de/nvidia.html

Oh hee die is boeiend. Misschien check ik die komend weekend even uit als ik wat meer tijd heb. Thanks!

[Verwijderd]

Verwijderd schreef op 18 maart 2003 @ 09:10:
Huh ? wat ist ? en hoe ist met die labrat ?

.

[blouweKip]

Oh hee die is boeiend. Misschien check ik die komend weekend even uit als ik wat meer tijd heb. Thanks!

In gentoo gooit hij atutomatisch die patches eroverheen als je de nvidia drivers installeert, en de driver werken prima dan

* blouweKip is zeer tevreden met 2.5.64, alleen alsa zuigt nog steeds

[Verwijderd]

Eerste indrukken van 2.5.64.

Ik heb lang gewacht met upgraden omdat ik eigenlijk wilde wachten op die schedular patch. Het compileren en installeren gaf geen problemen. Ik loop eigenlijk maar tegen drie zaken aan.

1. QM_MODULE niet gevonden: Met geen mogelijkheid weg te krijgen. Ook niet na installatie van
de nieuwe module-init-tools. Uiteindelijk dus maar alles in de kernel gecompileerd wat ik nodig dacht te hebben waardoor mn kernel tikkie groter is geworden dan ik had gewild.

2. melding bij draaien van /sbin/lilo -v: Kernel & BIOS return differing head/sector geometries
for device 0x80. Hier heb ik geen oplossing voor gevonden behalve bemoedigende woorden dat er niet zoiets als geometry bestaat en dat de melding niet erg is. Dat laat ik dan maar zo.

3. Op de 1 of andere vreemde wijze zijn mn dirs niet leesbaar bij een "ls" vanuit console 2 en hoger. Ik krijg allerlei scrambeld output. De files zijn wel goed.. In console 1 is alles prima. Vanuit X en dan in een console is ook alles prima. Ik vermoed dat dit iets met het framebuffer support heeft te maken wat ik niet heb meegecompileerd maar ik kan niet verklaren waarom in console 1 het wel goed is en de anderen niet. Ik heb ook nog niet gezocht op google of meer mensen dit probleem herkennen.

Overall conclusie tot nu toe: Ik ben blij dat ik de upgrade heb gedaan. Desktop loopt stukken soepeler dan voorheen. Ik ben zeer content. Het starten van sommige programma's is ook verbeterd maar in grote lijnen hetzelfde gebleven. Gnome2.2 start langzamer op dan voor de upgrade maar dit is denk ik te wijten aan het gebruiken van de nv driver i.p.v. nvidia.

Als ik zo de mn post doorlees lijkt het toch wel wat negatief allemaal maar zo bedoel ik het zeker niet. Ik merk een flinke desktop performance verbetering en geen tot weinig stotteringen meer met de muis. Voorheen had ik daar nog al eens last van met dropline-gnome2.2 op een PIII-500. Ik merkte altijd dat mn machine het maar net allemaal kon draaien maar nu met de nieuwe kernel lijkt het wel alsof er nog capaciteit over is. Cool dus.

[Verwijderd]

2.5.65 is al uit hoor.

Net gecompileerd, is er volgens mij wat mis met de framebufferdrivers (Mach64) - zie niks.

De GTK2 configger werkt wel fijn trouwens.

[Verwijderd]

WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide-probe.ko needs unknown symbol ide_xlate_1024
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide-probe.ko needs unknown symbol create_proc_ide_interfaces
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide-probe.ko needs unknown symbol ide_bus_type
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide-probe.ko needs unknown symbol do_ide_request
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide-probe.ko needs unknown symbol ide_add_generic_settings
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol ide_scan_pcibus
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol ide_release_dma
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol create_proc_ide_interfaces
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol ide_add_proc_entries
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol proc_ide_read_capacity
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol destroy_proc_ide_drives
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol ide_probe_for_cmd640x
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol proc_ide_destroy
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol ide_remove_proc_entries
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol cmd640_vlb
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide.ko needs unknown symbol proc_ide_create
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide-floppy.ko needs unknown symbol proc_ide_read_geometry
WARNING: /lib/modules/2.5.65/kernel/drivers/ide/ide-disk.ko needs unknown symbol proc_ide_read_geometry
WARNING: Module /lib/modules/2.5.65/kernel/drivers/scsi/ide-scsi.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide-taskfile.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide-probe.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide.ko ignored, due to loop
WARNING: Loop detected: /lib/modules/2.5.65/kernel/drivers/ide/ide-iops.ko needs ide.ko which needs ide-iops.ko again!
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide-iops.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide-io.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide-geometry.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide-floppy.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide-disk.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/ide/ide-cd.ko ignored, due to loop
WARNING: Module /lib/modules/2.5.65/kernel/drivers/usb/storage/usb-storage.ko ignored, due to loop

sigh..
_{(jaja, ik heb de nieuwste module-init-blah geinstalleerd)}

Njah, vind ik wel iets op..

En /me is errug blij met gconfig, veel mooier

Nu maar hopen dat ik straks m'n systeem nog kan rebooten
_{(vanwege het gekl**t in /sbin met ksyms, kallsyms en die module zut)}

[deadinspace]

Verwijderd schreef op 18 maart 2003 @ 07:45:
O(1) dood? .

AFAICT zijn deze nieuwe scheduler dingen aanpassingen aan de O(1) scheduler.

Nog steeds O(1) dus, maar dan verbouwd

Verwijderd schreef op 18 maart 2003 @ 18:27:
Eerste indrukken van 2.5.64.

Ik heb lang gewacht met upgraden omdat ik eigenlijk wilde wachten op die schedular patch.

Volgensmij zitten die interactivity-wijzigingen nog niet in 2.5.64, maar pas in 2.5.65, dus wellicht wil je die ook proberen.

3. Op de 1 of andere vreemde wijze zijn mn dirs niet leesbaar bij een "ls" vanuit console 2 en hoger. Ik krijg allerlei scrambeld output. De files zijn wel goed.. In console 1 is alles prima. Vanuit X en dan in een console is ook alles prima. Ik vermoed dat dit iets met het framebuffer support heeft te maken wat ik niet heb meegecompileerd maar ik kan niet verklaren waarom in console 1 het wel goed is en de anderen niet.

Weet je zeker dat je geen framebuffer hebt? Heb je standaard 80x25 VGA hardware text mode, of iets anders?

Als ik zo de mn post doorlees lijkt het toch wel wat negatief allemaal maar zo bedoel ik het zeker niet. Ik merk een flinke desktop performance verbetering en geen tot weinig stotteringen meer met de muis.

Een groot aandachtspunt in 2.5 is fairness, interactivity en lage latencies (drie dingen die veel effect hebben op de "vloeiendheid"), maar die dingen kunnen in beperkte mate ten koste van performance gaan. De nieuwe I/O scheduler zou daarentegen een verbeterde performance moeten bieden.

Misschien is het interessant om een beetje te experimenteren of en wat er langzamer geworden is. Duurt een kernel compile langer? CPU-intensieve taken (iets uitrekenen met bc bijvoorbeeld)?

[Verwijderd]

Het wordt met name langzamer als meerdere processen om CPU tijd vragen, dus tien compiles tegelijk ofzo... Als er slechts 1 proces actief is, dan is de scheduler niet merkbaar langzamer dan normaal... (denk ik).

[Wirf]

Verwijderd schreef op 18 maart 2003 @ 18:27:
3. Op de 1 of andere vreemde wijze zijn mn dirs niet leesbaar bij een "ls" vanuit console 2 en hoger. Ik krijg allerlei scrambeld output. De files zijn wel goed.. In console 1 is alles prima. Vanuit X en dan in een console is ook alles prima. Ik vermoed dat dit iets met het framebuffer support heeft te maken wat ik niet heb meegecompileerd maar ik kan niet verklaren waarom in console 1 het wel goed is en de anderen niet. Ik heb ook nog niet gezocht op google of meer mensen dit probleem herkennen.

dit is een gokje, maar goed:

probeer dit eens in console 2: echo $TERM
Als daar iets anders uit komt dan "linux" doe dan: export TERM=linux

[Verwijderd]

Ik heb hier zojuist 2.5.65 gecompiled, maar bij het booten blijft de kernel hangen op "Decompressing Linux...", waarna hij dus volledig vast zit (ctrl-alt-del wil ook niet meer)...

Draait op een verse Gentoo Linux 1.4_rc3 install...

Iemand die dit ook heeft gehad en heeft opgelost ?

[Verwijderd]

Verwijderd schreef op 21 March 2003 @ 08:09:
Ik heb hier zojuist 2.5.65 gecompiled, maar bij het booten blijft de kernel hangen op "Decompressing Linux...", waarna hij dus volledig vast zit (ctrl-alt-del wil ook niet meer)...

Draait op een verse Gentoo Linux 1.4_rc3 install...

Iemand die dit ook heeft gehad en heeft opgelost ?

Ik heb hetzelfde..

Volgende melding staat op het scherm:

code:

Booting 'Linux 2.5.65'

root (hd0,6)
  Filesystem type is ext2fs, partitiontype 0x83
kernel /boot/vmlinuz-2.5.65 ro root=/dev/hda7 hdc=ide-scsi
  [linux-bzImage, setup=0x1400, size=0xe53f5]
initrd /boot/initrd-2.5.65.img
  [linux-initrd @ 0xffa3000, 0x383f6 bytes]

Uncompressing Linux... Ok, booting the kernel.

En dan doet en reageert er helemaal niets meer, inclusief ctrl-alt-del en de ledjes op het keyboard.
_{(dit is op Red Hat 8.0 btw)}

Ik denk zelf dat ik toch echt eerst die waarschuwingen van m'n vorige post moet zien op te lossen..

[Quinny]

Ik heb 2.5.65 gisteren gecompiled op mijn laptop, acpi support werkt nu eindelijk goed (ik kan de batterijstatus zien in gkrellm) en X voelt iets vloeiender.

Als ik in een rxvt term iets ga compilen word mijn hele systeem traag, met kernel 2.4.20 had ik hier geen last van, alles bleef gewoon normaal werken. En zijn de letters soms een beetje slecht gerenderd, een paar extra pixels hier en daar...

Ook crashed op deze kernel mozilla (bij mij) bij de eerste site die ik open word mijn hele mozilla venster grijs en ik kan het process ook niet killen, een reboot is de enige oplossing.
Ik had mozilla 1.3 gecompiled met gtk2 support, eerst dacht ik dat dit het was, maar na mozilla gecompiled te hebben zonder gtk2 support bleef hij crashen.

Binnenkort even proberen of mozilla ook crashed als ik gnome uitzet...

Het compilen ging verder zonder fouten, de eerste keer dat ik een experimentele kernel probeer nog wel

Distro is trouwens Gentoo (met ACCEPT_KEYWORDS="~x86")

[ Voor 1% gewijzigd door Quinny op 21-03-2003 15:34 . Reden: spelfouten ]

[odysseus]

Quinny schreef op 21 March 2003 @ 15:32:
Als ik in een rxvt term iets ga compilen word mijn hele systeem traag, met kernel 2.4.20 had ik hier geen last van, alles bleef gewoon normaal werken.

Dat zou wel eens een probleem met de nieuwe tweaks aan de scheduler kunnen zijn. Die geeft interactieve processen een 'priority-boost'. De kernel kan natuurlijk niet zo makkelijk uitmaken wat een interactief proces is, maar ik meen dat er nu voor het eerst een soort child-tracking in het gebruikte algoritme is ingebouwd. Aangezien XFree86 als interactief wordt gezien, zal ook rxvt en daarmee de compilatie binnen je rxvt als interactief worden gezien en daarom meer processortijd krijgen, die ten koste gaat van andere processen.

* odysseus weet overigens niet zeker of die 'subprocess-tracker' al in 2.5.65 zit...staat wel ergens op kerneltrap.org te lezen .

[Verwijderd]

Verwijderd schreef op 21 maart 2003 @ 13:32:
Ik denk zelf dat ik toch echt eerst die waarschuwingen van m'n vorige post moet zien op te lossen..

Nog even wat meer informatie voor de mensen die met dezelfde problemen zitten:

Ik ben de waarschuwingen nu eindelijk kwijt door de betreffende code in de kernel te compileren ipv als module(s).
Dit was bij mij ook het geval bij de vorige 2.5 kernel die ik had geprobeerd (en gelukkig nog een .config van had liggen).
Om een of andere vage reden lukt het met gconfig niet om bepaalde onderdelen in de kernel zelf op te nemen (ie. 'y' lukt niet, 'm' wel), waardoor sommige onderdelen (waaronder het ide/pci spul) alleen maar als module konden worden gebouwd.
Dit kan worden opgelost door .config met de hand te editten (en onderdelen als CONFIG_BLK_DEV_IDE, CONFIG_BLK_DEV_IDEDISK, CONFIG_BLK_DEV_IDEPCI en nog een paar op 'y' te zetten ipv 'm').

/me gaat nú testen of het ook heeft geholpen tegen de vastloper..

edit:
w00t! Hij b00t!

Jammer dat ik nu nog steeds dezelfde boodschap te zien krijg en de boel opstart op de achtergrond omdat ie volgens m'n bootlog geen toegang kan krijgen tot /dev/tty0

[ Voor 13% gewijzigd door Verwijderd op 21-03-2003 18:01 ]

[blouweKip]

Ik had mozilla 1.3 gecompiled met gtk2 support, eerst dacht ik dat dit het was, maar na mozilla gecompiled te hebben zonder gtk2 support bleef hij crashen.

Dit is een mozilla probleem, 1.3beta had geen problemen met 2.5.64 en 65 bij mij

1.3 kan ik echter niet met gtk2 compilen, zelfs als ik met WANT_GTK2="yes" compile (zoals de ebuild zegt) dan nog compiled hij vrolijk voor gtk1 (wat opzich hinderlijk is als je galeon2 wilt compilen)

Nu nog zon crashhandler in mozilla zoals in galeon

[AlterEgo]

Verwijderd schreef op 21 maart 2003 @ 17:38:
[...]
Om een of andere vage reden lukt het met gconfig niet om bepaalde onderdelen in de kernel zelf op te nemen (ie. 'y' lukt niet, 'm' wel), waardoor sommige onderdelen (waaronder het ide/pci spul) alleen maar als module konden worden gebouwd.
Dit kan worden opgelost door .config met de hand te editten (en onderdelen als CONFIG_BLK_DEV_IDE, CONFIG_BLK_DEV_IDEDISK, CONFIG_BLK_DEV_IDEPCI en nog een paar op 'y' te zetten ipv 'm').

Met make menuconfig kan ik dit niet reproduceren.
Met gconfig trouwens ook niet
Kernel 2.5.65

[Verwijderd]

Waarschijnlijk staat een dependency dan op 'm'.

[Cyril]

Is er trouwens iemand die die nieuwe grafische config tooltjes prettig vind werken? De 'oude' xconfig viel nog wel mee, maar met de nieuwe kan ik echt niet overweg. Slechte onoverzichtelijke interface en grote trees die ook niet bepaald lekker werken. Ik geloof niet dat dit echt een vooruitgang is, geef mij maar gewoon m'n menuconfig.

[Semetrix]

Ik vind de nieuwe menuconfig wel lekker, niet dat er zoveel is veranderd.. maar file systems ziet er nu een stuk overzichtelijker uit.

ik probeerde net me 2.5.65-bk1 te patchen naar bk2, maar kreeg allemaal meldingen dat files aan aangepast waren en of ik die alsnog wou patchen.

ik heb maar standaard gekozen (wat [n] was) compilen doet die wel, maar ik vertrouw het toch niet helemaal.. is het veilig om nog een keer een file te patchen ?

oops verkeerde nick :x

<-- exci :x

[ Voor 5% gewijzigd door Semetrix op 21-03-2003 22:27 ]

[wzzrd]

* wzzrd vindt het lastig om zijn Intellimouse Explorer ( ) aan de praat te krijgen met een 2.5.x kernel.

Overigens, ik krijg tijdens het starten van Linux iets als

code:

* Setting user font
Format: 3
Format: 3
Format: 3
Format: 3
Format: 3
Format: 3
Format: 3

voorbij. Iemand die weet wat dat is?

[Verwijderd]

Verwijderd schreef op 21 March 2003 @ 21:52:
Waarschijnlijk staat een dependency dan op 'm'.

Daar zat ik ook idd al naar te zoeken maar ik heb nog steeds niet gevonden welke dependency precies op 'm' staat ipv 'y'

Een of andere 'automatic dependency resolution' zou in dit geval zeker wel op z'n plaats wezen in al deze ***config programmaatjes..

Ik ben er trouwens net achter dat ik geen ondersteuning voor de framebuffer had aangezet (en dus daarom waarschijnlijk geen tty's had).
_{(in de helptekst stond dat je dit rustig uit kon laten.. ik zal maar niet meer al te veel op die teksten vertrouwen )}

edit:
okee.. dat was het probleem dus ook niet..

edit:
argh.. blijkt net dat die stomme scrollbar van gconfig standaard () een klein stukje naar beneden gescrolled staat zodat ik niet de eerste optie zag in de char devices sectie..

nu zou het dus wel moeten werken..

[ Voor 28% gewijzigd door Verwijderd op 22-03-2003 07:41 ]

[Verwijderd]

wzzrd schreef op 21 March 2003 @ 23:39:
* wzzrd vindt het lastig om zijn Intellimouse Explorer ( ) aan de praat te krijgen met een 2.5.x kernel.

Dat is eigenlijk nog het minst moeilijke van alles
Bij mij:

CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y

_{(wanneer die muis driver als module wordt gecompileerd kunnen de init scripts van RH8 em bij mij niet vinden en kan ik m'n Intellimouse Explorer niet gebruiken)}

En bij mij werkt het nu eindelijk, w00t!
Maar er is nog 1 iets wat niet werkt en dat heb ik ook nog niet aan het werk gekregen met andere 2.5 kernels: het netwerk spul..

Ik krijg iedere keer maar weer de melding dat eth0 niet bestaat (/sbin/ifup scriptje werkt daardoor dus niet)
Iemand een idee hoe ik dat kan oplossen?
_{(onder Red Hat 8.0)}

[Verwijderd]

dikkebanaan: heb je de goede modules wel geladen (laden ze uberhaupt)?

[Verwijderd]

Verwijderd schreef op 13 March 2003 @ 19:22:
Like? .

XFree doet alle soorten acceleraties die er zijn, maar omdat de interface en structuur wat moeilijk lijkt vinden mensen het kut. Heb je nou al eens werkelijk tests gedaan of het sneller zou worden als je een directe local-only blabla windows-achtige GUI bouwt? Wordt het sneller? Ligt dat aan X?

Een van de manieren om dit sneller te maken is directfb, maar dat is geen optie voor een X server. Directfb zou een X extensie kunnen zijn, maar voor de rest kan X zoveel meer... Die tiende van een duizendste van een seconde kan mij dan echt geen ruk schelen...

Ik had dit nog niet gelezen maar zou hier toch nog even op willen reageren, ook al is het offtopic (misschien moet er een XFree86 draadje worden geöpend?).

Een paar die ik nu snel kan bedenken:

- Brakke muis deceleratie
- Geen ondersteuning voor bv andere kleurmodellen (blegh, 32 bpp fb wordt niet eens normaal ondersteund)
- XFree86 zal in dit tempo hopeloos achterlopen wanneer de rest van de wereld over gaat op een UI die gebruik maakt van de 3d hardware (zie OS X en Longhorn)
- Tekenen van wm/app is brak (ie. zoals al eens vaker is uitgelegd door Havoc Pennington zou XFree86 alles in 1 stap, of eigenlijk op een manier tekenen waarop de gebruiker niet ziet dat de wm + app 2 verschillende onderdelen zijn)

Maar het ergste vind ik eigenlijk toch wel dat de meeste van die zgn 'core developers' van XFree86 tegenwoordig alleen nog maar op hun reet zitten toe te kijken, zitten te zeiken over politiek spul en tegenwoordig nooit meer een enkele regel code schrijven voor XFree86.
Een van deze core developers is zelfs overgelopen naar Windows (!) ik begrijp echt niet wat die kerel (en de andere 'backseat developers') in zo'n team zoekt als ie toch liever andere software gebruikt (zoals is aangegeven door hem zelf) en ook al een hele hoop jaren *niets* meer heeft gedaan om XFree86 vooruit te helpen..

_{(hier wordt btw op dit moment ook over gediscussiëerd op een nieuwe mailing list @ xfree86.org, naar aanleiding van het eruit schoppen door het core team van de enige developer die _wel_ veel deed om XFree86 te verbeteren)}

Het gaat mij iig helemaal niet meer om de snelheid op dit moment, dat zit wel goed wanneer de (1-na-laatste) closed source driver van NVIDIA wordt gebruikt (ik weet niet hoe stabiel/snel die van ATi is?)

Nu weer ontopic:

Verwijderd schreef op 22 March 2003 @ 10:47:
dikkebanaan: heb je de goede modules wel geladen (laden ze uberhaupt)?

Voor zover ik weet wel maar ik zal zometeen voor de laatste keer nog eens alles nalopen.
Andere dingen werken nl ook nog niet echt lekker.. (dma voor m'n HD kan ik bv niet aanzetten, krijg de volgende melding: "HDIO_SET_DMA failed: Operation not permitted" (volgens Google moet ik ondersteuning voor m'n Via hw aanzetten, maar voor zover ik kan zien staat dat al aan), hierdoor hapert m'n muis tijdens HD activiteiten)

[Mon]

Ik heb dus vandaag ook eindelijk 2.5.65 maar eens geprobeerd. Beetje rondgekeken in menuconfig, relevante dingen veranderd en compilen maar. Dit ging goed, totdat ik wilde booten. Namelijk het bekende: "OK booting kernel..." en dan dus helemaal niets. Toen heb ik hier gekeken en zag ik dat je een framebuffer ding moest aanzetten (weet het zo niet uit mn hoofd) dat gedaan en nu krijg ik bij het compilen een paar keer Undefined Reference To 'set_con2fb_map' Kan iemand me verder helpen?

[Verwijderd]

_Mon_ schreef op 22 maart 2003 @ 18:42:
en zag ik dat je een framebuffer ding moest aanzetten

Dat dacht ik eerst ja, maar later bleek het zo te wezen dat ik een andere optie over het hoofd had gezien

Ga naar de sectie "Character Devices" en daarbovenaan moet je 'Virtual terminal' aanzetten, waarna er een nieuwe optie verschijnt: "Support for console on virtual terminal", deze moet je ook aanzetten.

Zonder bovenstaande kan je trouwens geen keyboard gebruiken en blijft het scherm 'hangen' op "Uncompressing Linux... blah"

[Verwijderd]

Verwijderd schreef op 22 maart 2003 @ 17:50:
- XFree86 zal in dit tempo hopeloos achterlopen wanneer de rest van de wereld over gaat op een UI die gebruik maakt van de 3d hardware (zie OS X en Longhorn)

Dat is een applicatie kwestie, niet een X kwestie...

- Tekenen van wm/app is brak (ie. zoals al eens vaker is uitgelegd door Havoc Pennington zou XFree86 alles in 1 stap, of eigenlijk op een manier tekenen waarop de gebruiker niet ziet dat de wm + app 2 verschillende onderdelen zijn)

Double buffering, bedoel je? Eens.

Maar het ergste vind ik eigenlijk toch wel dat de meeste van die zgn 'core developers' van XFree86 tegenwoordig alleen nog maar op hun reet zitten toe te kijken, zitten te zeiken over politiek spul en tegenwoordig nooit meer een enkele regel code schrijven voor XFree86.
Een van deze core developers is zelfs overgelopen naar Windows (!) ik begrijp echt niet wat die kerel (en de andere 'backseat developers') in zo'n team zoekt als ie toch liever andere software gebruikt (zoals is aangegeven door hem zelf) en ook al een hele hoop jaren *niets* meer heeft gedaan om XFree86 vooruit te helpen..

Mjah, I know... Kutzooi aldaar... Zegt op zich weinig over X, meer over de XFree86 devvers... .

Waar ik bang voor ben, is dat bedrijven als ATI en nvidia heel lang zullen achteroverleunen qua commerciele driver development als de X standaard wordt weggegooid. Dat is toch het belangrijkste wat er nodig is om commerciele bedrijven zover te krijgen Linux te supporten...

En wees eerlijk, die opensource nv drivers zijn peanuts vergeleken met de nvidia drivers, geen discussie mogelijk...

Anyway, ik draai sinds een paar uurtjes 2.5.65 en heb al wat shcoonheidsfoutjes gezien. . Ik zal nog wel ff verdertesten vanavond.

[odysseus]

Verwijderd schreef op 22 maart 2003 @ 21:27:
Dat is een applicatie kwestie, niet een X kwestie...

Als je elke applicatie zijn eigen communicatie met 3D-hardware wilt laten uitvoeren, dan mag je, maar mij lijkt het niet handig . Natuurlijk kan een programma indien nodig SDL en dergelijke gebruiken, maar dat is duidelijk iets anders. Om zoiets echt te integreren, zou ik het liever op het niveau van X geïmplementeerd zien dan binnen KDE of Gnome. Tenslotte heeft XFree86 de benodigde hardwaretoegang, die bovenopliggende programma's niet altijd even makkelijk krijgen.

[balk]

Verwijderd schreef op 22 March 2003 @ 19:41:
[...]


Dat dacht ik eerst ja, maar later bleek het zo te wezen dat ik een andere optie over het hoofd had gezien

Ga naar de sectie "Character Devices" en daarbovenaan moet je 'Virtual terminal' aanzetten, waarna er een nieuwe optie verschijnt: "Support for console on virtual terminal", deze moet je ook aanzetten.

Zonder bovenstaande kan je trouwens geen keyboard gebruiken en blijft het scherm 'hangen' op "Uncompressing Linux... blah"

Ik had hetzelfde... een mooi zwart scherm en een keyboard dat niks doet Volgende stap was: wel beeld maar onleesbare letters Nu doet ie het wel, maar ik krijg mij USB muis niet aan de praat. Instellingen zijn exact hetzelfde als in 2.4.20 maar helaas. Ik heb de ouwe psaux muis maar weer van stal gehaald. Verder draait deze kernel erg soepel, al heb ik nog weinig spannends gedaan.

Cyril schreef op 21 March 2003 @ 21:54:
Is er trouwens iemand die die nieuwe grafische config tooltjes prettig vind werken? De 'oude' xconfig viel nog wel mee, maar met de nieuwe kan ik echt niet overweg. Slechte onoverzichtelijke interface en grote trees die ook niet bepaald lekker werken. Ik geloof niet dat dit echt een vooruitgang is, geef mij maar gewoon m'n menuconfig.

ik heb dat gconfig geprobeerd, maar ben weer gauw terug gerent naar menuconfig..... Het is leuk om te laten zien aan mensen "Kijk, Linux is niet spartaans", maar verder

[Verwijderd]

odysseus schreef op 22 March 2003 @ 21:32:
Als je elke applicatie zijn eigen communicatie met 3D-hardware wilt laten uitvoeren, dan mag je, maar mij lijkt het niet handig . Natuurlijk kan een programma indien nodig SDL en dergelijke gebruiken, maar dat is duidelijk iets anders. Om zoiets echt te integreren, zou ik het liever op het niveau van X geïmplementeerd zien dan binnen KDE of Gnome. Tenslotte heeft XFree86 de benodigde hardwaretoegang, die bovenopliggende programma's niet altijd even makkelijk krijgen.

Maar die interface is er al lang. openGL.

[Verwijderd]

Verwijderd schreef op 22 March 2003 @ 21:27:
Dat is een applicatie kwestie, niet een X kwestie...

Ik heb het over een _widget toolkit_ die direct gebruik maakt van de hardware.
Dan bedoel ik dus dat Gtk en Qt dat moeten doen, niet de applicatie zelf ^[1]

Double buffering, bedoel je? Eens.

Dat zou idd een van de (beste) manieren wezen om dat probleem helemaal uit de wereld te helpen.
Voorlopig wordt er nog een hoop gehackt.. (zie xsync patches voor Gtk2/Metacity)

Mjah, I know... Kutzooi aldaar... Zegt op zich weinig over X, meer over de XFree86 devvers... .

Tjah.. het is te hopen dat er een fork komt.. die core developers lopen alleen maar uit hun (al dan niet virtuele) neus te vreten.

Waar ik bang voor ben, is dat bedrijven als ATI en nvidia heel lang zullen achteroverleunen qua commerciele driver development als de X standaard wordt weggegooid. Dat is toch het belangrijkste wat er nodig is om commerciele bedrijven zover te krijgen Linux te supporten...

En wees eerlijk, die opensource nv drivers zijn peanuts vergeleken met de nvidia drivers, geen discussie mogelijk...

btw. Lees dit stukje text van 9 Januari ook eens door (nog meer sappige roddels en achterklap ):
http://www.advogato.org/person/mharris/


[1] Meer:

Verwijderd schreef op 23 March 2003 @ 03:51:
[...]


Maar die interface is er al lang. openGL.

Je dacht toch niet echt dat mensen hun progs allemaal gaan maken op de 'Blender manier'?

[Verwijderd]

Hoe bedoel je? Er is een openGL extensie in X, er zijn GtkGL widgets (er is vast ook een QtGL widget)... Wat wil je nog meer dan? Een toolkit die jouw gedachten uitleest en daar automatisch bugloze code van maakt? Ik dacht dat we die academische prutzooi (Linus: "build a solution so much around the problem it addresses so, that it will face the same problems that the original solution did address") toch wel genoeg hadden bediscussieerd nu...

Wat willen jullie nou dan?

[Mon]

dikkebanaan schreef oa.:
[...]


een nieuwe optie verschijnt: "Support for console on virtual terminal", deze moet je ook aanzetten.

Als je wilt moet je dat even nakijken want ik kan deze optie toch echt niet vinden... of ik doe nu 4x al iets grandioos fout ofzo...

[Verwijderd]

_Mon_ schreef op 23 March 2003 @ 21:58:
[...]


Als je wilt moet je dat even nakijken want ik kan deze optie toch echt niet vinden... of ik doe nu 4x al iets grandioos fout ofzo...

Ik heb net nog even gekeken, maar ik heb em wel aanstaan, maar toch blijft de boot nog hangen op 'Uncompressing Linux...'

[Mon]

ja ik heb dus precies hetzelfde... Ik neem aan dat er nog een optie meegecompileerd moet worden ofzo ? als iemand enig idee heeft houd ik me aanbevolen.

[AlterEgo]

Mijn .config voor 2.5.65
Met werkende consoles en framebuffers.
Ahtlon; KT333; ide-scsi-CDR; zoiets.
Als je er iets aan hebt

[ Voor 3% gewijzigd door AlterEgo op 24-03-2003 17:15 ]

[Verwijderd]

AlterEgo schreef op 24 maart 2003 @ 17:14:
Mijn .config voor 2.5.65
Met werkende consoles en framebuffers.
Ahtlon; KT333; ide-scsi-CDR; zoiets.
Als je er iets aan hebt

Ah thx dude vanavond ff mee spelen

[Cyril]

AlterEgo schreef op 24 maart 2003 @ 17:14:
Mijn .config voor 2.5.65
Met werkende consoles en framebuffers.
Ahtlon; KT333; ide-scsi-CDR; zoiets.
Als je er iets aan hebt

Met 2.5.x heb je geen ide-scsi meer nodig voor cd burning. ide-cd werkt prima, is zelfs sneller en minder cpu intensief. Helaas is er nog geen scanbus support, dus moet je 't nog handmatig opgeven bij cdrecord (met dev=/dev/hdx). Ook cdrdao werkt nog niet met ide-cd, maar de cvs versie moet werken geloof ik.

[deadinspace]

Ik heb (ook met het oog op de recente gebeurtenissen rondom het XFree86 core team) een discussie over XFree86 geopend. Gelieve daar over XFree86 verder te discussieren en niet hier. Danku


Linux 2.5 lijkt inmiddels in het zeur-als-het-niet-werkt stadium aangekomen te zijn. Problemen met (het compilen van) drivers en dergelijke moeten dus gemeld worden als je ze ooit werkend wil zien.

Zie ook http://www.linuxjournal.com/article.php?sid=6740 :

A lot of people ask me, "When do you think the 2.6 kernel will be released?" My response to that question usually is, "Well, how well is the 2.5 kernel working for you?"

[ Voor 16% gewijzigd door deadinspace op 24-03-2003 22:38 ]

[Cyril]

2.5.66 is uit..

announcement:

A lot of changes all over. Most notably probably the fbcon updates, it's
really all over the map - mostly a lot of very small fixes.

Linus

Patch
Changelog
Source tarball

[Verwijderd]

Wirf schreef op 18 april 2002 @ 16:32:
[...]


[slightly offtopic]

Serial ATA is (AFAIK) software-compatible met "gewone" ATA hoor, dus het maakt voor linux helemaal niets uit. IDE-SCSI blijft voorlopig dus nog wel (helaas)

Ik weet niet waarom iedereen dat steeds zegt, want ik heb al een tijd geleden gelezen dat native ATAPI CD-rewriter support (dus zonder SCSI-emulatie) al in de 2.5.x kernels is opgenomen en binnenkort zelfs gebackport gaat worden naar 2.4. Die announcement ging als ik me goed kan herinneren tevens gepaard met een oproep aan iedereen die Linux CD writing apps schreef om hun software compatbile te maken met deze nieuwe ATAPI support.

En it's about freaking time wat mij betreft, trouwens.

[ Voor 16% gewijzigd door Verwijderd op 25-03-2003 01:57 ]

[Verwijderd]

/me verklaart hierbij dat zijn grootste driver irritatie sinds gisternacht is opgelost... 1 bug remaining, en dan kan 'ie in 2.5.x.

Binnenkort Jotti in de kernel. .

[Wirf]

Verwijderd schreef op 25 maart 2003 @ 01:54:
Ik weet niet waarom iedereen dat steeds zegt [..]

dude, dat berichtje is al bijna een jaar oud

[Verwijderd]

Eh... Oeps...

[AkaXakA]

Verwijderd schreef op 25 March 2003 @ 08:03:
/me verklaart hierbij dat zijn grootste driver irritatie sinds gisternacht is opgelost... 1 bug remaining, en dan kan 'ie in 2.5.x.

Binnenkort Jotti in de kernel. .

*Schrik* Jotti in kernel !

Maar, ehm, om welke driver gata het dan?

[bkor]

Cyril schreef op 24 March 2003 @ 19:18:
Ook cdrdao werkt nog niet met ide-cd, maar de cvs versie moet werken geloof ik.

Bedankt voor deze hint! Cdrdao is nu een simulatie aan het doen met /dev/hdc

De methode die ik heb gebruikt:
1. D/l de cdrdao CVS versie (werkt mogelijk ook met de laatste stabiele versie)
Voor instructies: http://sourceforge.net/cvs/?group_id=2171
2. D/l de laatste cdrtools alpha. Ik heb alpha05 gebruikt, maar 06 is al uit.
URL: ftp://ftp.berlios.de/pub/cdrecord/alpha
3. Start autogen.sh in cd cdrdao cvs directory. Dat script pakt pccts.tar.gz en scsilib.tar.gz uit
4. (cdrdao scsilib updaten) Vergelijk de directories cdrtools-2.01/ en cdrdao_cvs_ding/scsilib/. Vergelijk welke directories in beide locaties aanwezig zijn. Kopieer deze van cdrtools-2.0.1/ naar cdrdao_cvs_ding/scsilib/
5. Als je nu cdrdao zal compileren, zal het falen op een onbekende u8 in /usr/src/linux/include/scsi/scsi.h. Je kan dit netjes oplossen en op mijn manier.
Verander in dat scsi.h bestand op regel 204 u8 in unsigned char
6. make, make install

Resultaat:

code:

/dev/hdc: LITE-ON LTR-48246S    Rev: SS0A
Using driver: Generic SCSI-3/MMC (raw writing) - Version 2.0 (options 0x0000)
 
Starting write simulation at speed 16...
Pausing 10 seconds - hit CTRL-C to abort.
Process can be aborted with QUIT signal (usually CTRL-\).
Turning BURN-Proof on
resid: 98
Enabling JustSpeed.
Using 16 byte P-Q sub-channel data mode.
WARNING: No super user permission to setup real time scheduling.
Writing lead-in and gap...
Writing track 01 (mode MODE2_RAW/AUDIO )...
Writing track 02 (mode MODE2_RAW/AUDIO )...
Wrote 802 of 802 MB (Buffer 100%).
Wrote 357994 blocks. Buffer fill min 98%/max 100%.
Writing lead-out...
Wrote 15 of 15 MB.
Flushing cache...
Simulation finished successfully.

Indien gewenst kan ik een tar.gz (alleen de aangepaste scsilib, niet gecompileerd) en een Mandrake rpm op een webpage gooien (iemand webspace? ).

[Quinny]

Net meteen maar even 2.5.66 gedownload, ik zit toch op mijn stage... (eigen laptopje mee natuurlijk...)

Deze kernel is VEEL beter als 2.5.65! Geen van de problemen (zie mijn post op pagina 14) die ik had met 2.5.65 heb ik met 2.5.66, mozilla loopt perfect en als ik iets compile neemt dit niet meer mijn complete systeem in beslag, ik kan gewoon normaal doorwerken...

En de snelheid is net zo goed... Echt een aanrader =)

[Verwijderd]

Quinny schreef op 25 maart 2003 @ 16:50:
Deze kernel is VEEL beter als 2.5.65! Geen van de problemen (zie mijn post op pagina 14) die ik had met 2.5.65 heb ik met 2.5.66, mozilla loopt perfect en als ik iets compile neemt dit niet meer mijn complete systeem in beslag, ik kan gewoon normaal doorwerken...

Wat ging er dan mis of minder goed met Mozilla?

(zucht, weer updaten.. Linus geeft 'release early, release often' een compleet nieuwe definitie.. overdrijven is ook een vak )

[Quinny]

Verwijderd schreef op 25 March 2003 @ 18:23:
[...]


Wat ging er dan mis of minder goed met Mozilla?

(zucht, weer updaten.. Linus geeft 'release early, release often' een compleet nieuwe definitie.. overdrijven is ook een vak )

Mozilla crashde om de paar minuten, zomaar vast en kon het process niet killen

Ik heb 2.5.66 nu ook op mijn thuis systeem draaien, specs staan in mijn sig...

Tot nu toe twee onverklaarbare fouten gehad: een rxvt terminal die zomaar "verdween" en xchat2 die gewoon vast zat... (kill en xchat2 opnieuw gestart en nu draait hij al 20 minuten goed...)

Voor de rest gaat alles weer perfect...

[AlterEgo]

* AlterEgo heeft ook wel positieve eerste ervaringen met 2.5.66:

Eindelijk is alsa van de haperingen onder hoge load verlost (net als de changelog deed vermoeden), en zowaar: de Riva/Nvidia framebuffer doet het in combinatie met de nvidia-X-drivers (ook dat deeed de changelog wel vermoeden met zoveel FB updates).
Ook de USB aansturing van mijn scanner lijkt nu OK en vrij van "enge" geluiden.

Wat (mij) nog steeds niet lukt, is de CVS-versie van lm_sensors integreren in deze kernels.
Ik download de cvs-versie van i2c volgens instructies; genereer een patch; patch daarmee de kernel en recompileer. vervolgens compileer ik lm_sensors, en bij het uitproberen krijg ik de mededeling dat de modules van een "incomptible module type" zijn
Terwijl andere modules, ook "vreemde", prima modproben... suggesties gaarne

[Verwijderd]

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

[Verwijderd]

Hmm, vannacht dan maar ff kijken of ie bij mij ook wil (2.5.65 wilde niet booten)...

AlterEgo: die nvidia-fb: draait dat lekker? bv. sneller dan wanneer je alleen de nvidia-drivers voor X gebruikte (zoals ik nu doe onder 2.4.20-xfs-r2) ?

[AlterEgo]

Nvidia framebuffer draait op zich sneller dan vesa. En (tot mijn verbazing) werkte nvidia-fb ook in combinatie met de nvidia-X drivers. Maar: ik kon de FB-resoluties niet veranderen en bleef hangen op 640*480.
Wat ook niet lukte zonder een harde lockup: switchen van X naar een console (en dus ook normaal afsluiten vanuit X lukt niet).

Dus: je hebt er nog niet veel aan, maar er zit wel vooruitgang in.
Disclaimer: dit zijn mijn ervaringen op een Geforce 2MX die soms recalcitrant gedrag vertoont.

[Verwijderd]

AlterEgo schreef op 26 March 2003 @ 21:32:
(tot mijn verbazing) werkte nvidia-fb ook in combinatie met de nvidia-X drivers. [..] Wat ook niet lukte zonder een harde lockup: switchen van X naar een console (en dus ook normaal afsluiten vanuit X lukt niet).

Dat is dus juist de bug in nvidia-fb en/of de nvidia X drivers.

edit:
Zojuist nieuwe test-release uitgebracht van mijn driver voor 2.5.x... Zal het dan toch nog goedkomen ooit? .

[ Voor 15% gewijzigd door Verwijderd op 26-03-2003 23:03 ]

[Verwijderd]

Kernel 2.5.66:

Volledig
Patch
Changelog

[Verwijderd]

Verwijderd schreef op 27 March 2003 @ 17:58:
Kernel 2.5.66:

Volledig
Patch
Changelog

Ja, die was er een aantal dagen geleden ook al
_{(zie vorige pagina)}

[deadinspace]

http://kerneltrap.org/node.php?id=618

Steeds meer oproepen aan gewone users om de 2.5 kernel te testen

[Verwijderd]

Leuke feature in 2.5.x is dat bij een oops automatisch een backtrace kan worden gegenereerd. Fantastische optie, scheelt me eeuwen werk om users uit te leggen hoe ksymoops werkt. .

Overigens was ik niet bijzonder tevreden over 2.5.65, ik heb net 2.5.66 geinstalleerd - zal zo vanavond dus eens testen..

[ Voor 4% gewijzigd door Verwijderd op 28-03-2003 14:36 ]

[voodooless]

2.5.66 is wicked!

Bij mij doet ie het echt erg goed! Eerst kreeg ik hem niet geboot (wilde van /dev/md9) booten, maar toen ik "root=/dev/md0" in de kernel params zette werkte het (vaag dat lilo dat niet door geeft...)

Eerst had ik idd ook de fout met de modules die niet wilden laden, maar als je de module-init-tools opnieuw installeerd werkt het weer perfect.

Wat mij als eerste op viel was dat de SCSI snelheid omhoog was gegaan. ik kan nu 100 Mb/s lezen/schrijven op mijn RAID 0 array. Verder heb ik X incl nviadia 1.0.4191 driver aan de gang, en het werkt lekker snel (beter dan 2.4.20).

Als enigste probleem heb ik een half werkede bttv driver (heb de laatste versie van bytesex.org/bttv, 0.9.9 ofzo).

[Wirf]

Ik heb net de 2.5.66-mm1 kernel gecompiled en geinstalleerd. En ik moet zeggen dat die me nog beter bevalt dan de standaard 2.5.66; nog vloeiender en sneller dan dat 2.5.66 al was.

Deze hou ik dus voorlopig even


edit:

[...]
Als enigste probleem heb ik een half werkede bttv driver (heb de laatste versie van bytesex.org/bttv, 0.9.9 ofzo).

Uuh.. ik gebruik gewoon de standaard bttv driver die in de kernel zit zonder problemen?

[ Voor 29% gewijzigd door Wirf op 28-03-2003 16:51 ]

[voodooless]

Uuh.. ik gebruik gewoon de standaard bttv driver die in de kernel zit zonder problemen?

Hmm, die heb ik ook geprobeerd, maar ik krijg ook van allerhande messages van motv/xawtv terug. Die krijg ik bij beiden (standaard en nieuwe) en alleen als ik grabdisplay gebruik en niet overlay (will immers 1600x1200 full screen kijken). Misschien is de mm1 versie toch net weer ietje anders. Ik vermoed iets met de v4l api...

[Wirf]

deepspace schreef op 28 March 2003 @ 18:11:
Hmm, die heb ik ook geprobeerd, maar ik krijg ook van allerhande messages van motv/xawtv terug.

Zoals wat?

[..] alleen als ik grabdisplay gebruik en niet overlay [..] Misschien is de mm1 versie toch net weer ietje anders. Ik vermoed iets met de v4l api...

vreemd, ik gebruik anders ook grabdisplay en dat werkte ook bij de standaard 2.5.65 en 2.5.66 kernels

[voodooless]

dit bijvoorbeel:

ioctl: VIDIOC_S_FMT(type=VIDEO_CAPTURE;fmt.pix.width=384;fmt.pix.height=288;fmt.pix.pixelformat=0x32315559 [YU12];fmt.pix.field=ANY;fmt.pix.bytesperline=0;fmt.pix.sizeimage=221184;fmt.pix.colorspace=unknown;fmt.pix.priv=0): Device or resource busy

[Verwijderd]

deepspace schreef op 28 March 2003 @ 18:11:
Ik vermoed iets met de v4l api...

Lijkt me niet. Hoe trigger je dit? Ik wil zo wel ff kijken of ik 't ook heb...

[voodooless]

Lijkt me niet. Hoe trigger je dit? Ik wil zo wel ff kijken of ik 't ook heb...

Gewoon xawtv of motv opstarten en beeld scalen.

Verder zag ik nog wat in de ./configure van xawtv:

code:

checking for dev/ic/bt8xx.h... no
checking machine/ioctl_bt848.h usability... no
checking machine/ioctl_bt848.h presence... no
checking for machine/ioctl_bt848.h... no

Dit heeft er misschien iets mee te maken, maar met de 2.4 kernel (die gewoon werkt) heb ik deze files ook niet gehad (ze staan niet eens ergens op disk). Iemand een idee...

[ Voor 13% gewijzigd door voodooless op 28-03-2003 20:20 ]

[Verwijderd]

deepspace schreef op 28 maart 2003 @ 20:18:
Verder zag ik nog wat in de ./configure van xawtv:

code:

checking for dev/ic/bt8xx.h... no
checking machine/ioctl_bt848.h usability... no
checking machine/ioctl_bt848.h presence... no
checking for machine/ioctl_bt848.h... no

Dit heeft er misschien iets mee te maken, maar met de 2.4 kernel (die gewoon werkt) heb ik deze files ook niet gehad (ze staan niet eens ergens op disk). Iemand een idee...

Da's voor de BSD video interface, geloof ik...

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

[edit2]

deepspace schreef op 28 March 2003 @ 18:11:
Hmm, die heb ik ook geprobeerd, maar ik krijg ook van allerhande messages van motv/xawtv terug. Die krijg ik bij beiden (standaard en nieuwe) en alleen als ik grabdisplay gebruik en niet overlay (will immers 1600x1200 full screen kijken). Misschien is de mm1 versie toch net weer ietje anders. Ik vermoed iets met de v4l api...

Fullscreen kan ook via overlay met Xv-capable videokaarten.

[edit]

Nu heb ik 2.5.66 geprobeerd en ik blijf zwaar teleurgesteld...

Enkele klaagzangpunten van me:
• de helft compilet niet (m.n. in network stack).
• module_request() is nog steeds broken.
• smc-ultra module geeft bij elke handeling -EBUSY ("Device or Resource Busy") - en nee, hij's niet in gebruik. .

Nu zit ik met een twijfelgeval, ik bekeek voor de grap linux/module.h eens...

C:

/* Not Yet Implemented */
#define MODULE_AUTHOR(name)
#define MODULE_DESCRIPTION(desc)
#define MODULE_SUPPORTED_DEVICE(name)
#define MODULE_PARM_DESC(var,desc)

even later:

C:

/* DEPRECATED: Do not use. */
#define MODULE_PARM(var,type)                                               \
struct obsolete_modparm __parm_##var __attribute__((section("__obsparm"))) = \
{ __stringify(var), type };

Geweldig. De oude MODULE_PARM() werkt, maar is obsolete en de nieuwe is er nog niet eens. . Grappig Treurig genoeg werkt een tool als modinfo dus ook absoluut niet.

Iets wat ik helemaal niet snap:

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. .

[ Voor 74% gewijzigd door Verwijderd op 28-03-2003 23:08 ]

[MadCow*]

Yup is voor BSD, dit is het resultaat op FreeBSD-5.0:

code:

checking dev/ic/bt8xx.h usability... no
checking dev/ic/bt8xx.h presence... no
checking for dev/ic/bt8xx.h... no
checking machine/ioctl_bt848.h usability... yes
checking machine/ioctl_bt848.h presence... yes
checking for machine/ioctl_bt848.h... yes

_{ik meng me hier verder niet in, alleen wil ff als verduideling aangeven}