Linux distro's draaien niet op P4 door ontbreken CPUID

LinuxGram meldt dat Intel heeft bevestigd dat momenteel alleen Red Hat 7.0 en TurboLinux 6 op P4 systemen geïnstalleerd kunnen worden. Alle overige distro's weigeren dienst omdat zij geen info over de Pentium 4 in hun CPUID databases hebben. De Linux distributeurs zijn inmiddels op de hoogte van het problemen, maar hebben nog geen datum gegeven voor de release van een nieuwe CPUID:

Without a Pentium 4 ID the installation simply halts. Once new databases are ready, Intel says, just about any Linux distribution should run. When the other Linux vendors will have those databases ready is unclear.

Intel strategic planning staff engineer George Chen, who's been working with Linux ISVs to get the updates out, says that the new Red Hat 7.0 and TurboLinux 6 both have new CPUID databases that include Pentium 4 information. Both vendors have also come up with workarounds for older versions of their operating systems, downloadable from their web sites, he says. Chen notes that any distributions built using the Red Hat or Turbo installs - China's notorious Red Flag Linux, for instance - should also install on the Pentium 4 without a problem.

Reacties (76)

[Verwijderd]

Je kunt bij het opstarten van de kernel een parameter meegeven met daarin het (een) CPUID dus het lijkt me niet dat het een al te groot probleem is...lastig is het wel. Ik heb dit dacht ik uit een van de computerbladen (pcm, computer totaal of C'T).

[nospam]

Quote van een reactie op /.:

According to c't (german magazine), the problem is just with SMP-Kernels, that have problems to identify the IO-APIC to know the number of CPUs.

Quickfix: Boot with kernel parameter "noapic".

Dan kan je in ieder geval je kernel upgraden

[Verwijderd]

Waar is die controle op CPUID dan goed voor? Ik kan toch ook Win 3.11 op een P4 installeren en het lijkt me sterk dat die een database met een P4 erin heeft.

[Verwijderd]

waar is die CPUID dan goed voor?

Er zijn in het verleden nogal eens bugs geconstateerd in de processor zelf. Foof en FDIV waren de bekendste, maar er zijn er meer.
Door zo'n CPU-database te maken, kun je het systeem heel precies aanpassen aan de gevonden resultaten.

Windows kan dat niet. Daarom hoeft daar ook geen uitgebreide CPU-database in te zitten.

[arjenk|IA]

Windows kan dat niet. Daarom hoeft daar ook geen uitgebreide CPU-database in te zitten.

Flauwekul. Als je er geen verstand van Windows hebt hou er dan je mond over. Wat je over CPUID zegt klopt wel, en surprise, surprise ook Windows en (goede) Windows drivers bevatten code om processor bugs te omzeilen. Gebruik je boerenverstand.

edit:

Ok, kan aardiger. Maar ik word hier zo moe van... Een zinnige reactie had vermeld wat het verschil is tussen de manier waarop Linux en Windows bugs & features van verschillende CPU's aanpakken. Dat kan je inmiddels in deze thread uitgebreid lezen.

En ME laten crashen? Boeiuh Als je weet hoe 95, 98 & ME in elkaar steken is dat een eitje. Het is juist de kunst om apps te schrijven die Windows niet laten crashen, waarbij je ook nog eens de bugs omzeilt & je code ook draait op NT4/2000.

[Booster]

Ja, alleen wel raar dat je die dan eerst wel aan moet zetten (die workarounds)...

In MSCONFIG zit namelijk de optie om FDIV of F00F te omzeilen, alleen die optie staat standaard uit...

surprise, surprise ook Windows en (goede) Windows drivers

Dus misschien beschermd Linux standaard ALLE code tegen de F00F bug omdat ze die er zelf uitvist, en zorgt het ervoor dat zelfs programma's die gemaakt zijn de F00F-bug te activeren niet werken...
Terwijl je in windows makkelijk die F00F instructie kunt uitvoeren, want alleen Windows zelf en sommige drivers zijn met een workaround gebouwd...

Of heb ik het mis?

[Verwijderd]

ook Windows en (goede) Windows drivers bevatten code om processor bugs te omzeilen

wie had het hier over mond houden als je ergens geen verstand van hebt? FOOF even geprobeerd met Windows ME, en het crasht nog gewoon zoals het (eigenlijk niet) hoort. Dus in het vervolg wat aardiger antwoorden als je het zelf ook niet precies weet.

[Verwijderd]

Er zijn ook wel andere meer aardige manieren om te reageren op iemand anders zijn post

[Verwijderd]

Ja, maar die zijn 1 niet leuk
en 2 is dit een zeer gepaste reactie in ongeveer dezelfde trant

[Verwijderd]

wie had het hier over mond houden als je ergens geen verstand van hebt? FOOF even geprobeerd met Windows ME, en het crasht nog gewoon

Of je zet nu een optie aan die windows bij install uit heeft gezet, of je zit met een assembler direct op de CPU te spelen, hoe dan ook bewijst dit helemaal NIKS.

Optie staat niet voor niets uit, en direct op de CPU spelen is sowieso uit de boze, dus dat windows crasht is meer een kwestie van "DUH" in plaats van 'informatief'.

[Verwijderd]

Windows 3.11 draaid ook onder dos he? das nogal vreemd vergelijken zo.

[Bigs]

Het gaat om het idee. Windows 95 kent de P4 ook niet, maar die werkt er ook wel gewoon mee. Beetje raar dat Linux zo afhankelijk is van die CPUID, vooral ook omdat bijvoorbeeld de 486 de CPUID instructie nog niet kent .

[dnf]

nou, die oude procs kon je toch ook identificeren hoor - gewoon zien hoe een proc een bepaalde instructie behandelt - de microcode voor - ik zeg maar wat - een 32-bit mul instructie, geeft op een 286 iets compleet anders - zo zijn er tussen elk type processor wel peculariteiten te vinden.

Heel handig om te weten welke instructies je op het ding kan afschieten.

[TheGhostInc]

Op zich jammer dat ze dan niet een "routine" hebben ingebouwd dat als ze een processor niet herkennen deze proberen te benaderen als een "standaard" processor.

[mvds]

Die CPUID is nodig om te bepalen welke instructies er wel en welke niet naar de CPU gestuurd mogen worden. Het is gewoon om de CPU te indentificeren. Vandaar ook de naam CPU-ID (cpu identification)


* 786562 obsidian
eerste keer per ongeluk op de verkeerde gereageerd!

[Verwijderd]

k kan toch ook Win 3.11 op een P4 installeren

Maar win3 (ofwel DOS) draait alleen op i386, en niet op Alpha, MIPS, Arm en IBM mainframes. Dus dat lijkt me ook wel logisch.

[Verwijderd]

Maar win3 (ofwel DOS) draait alleen op i386, en niet op Alpha,...

Onzin, DOS draait op x86, niet alleen op i386, en dan ga je er aan voorbij dat er echt wel het een en het ander is veranderd van 8086->386->4/586.

[Verwijderd]

Zou de P4 voor MS gesponsoord zijn ?
hihihihi

[Jordi]

Dit probleem is gefixt in linux kernel 2.2.18, die net uit is gekomen
Little to worry.

[nospam]

Je vergeet één klein detail: je moet eerst kunnen booten voordat je je kernel kan upgraden...

[Buzzman]

moet dat dan niet als je een nieuwe proc erin zet?

[Bigs]

Ja zeg, je bent een linuxgebruiker of je bent het niet.. je kunt toch wel een de bootdisk van je distro hacken en er een nieuwe kernel opzetten .
Waar een wil is is een weg

[nospam]

Stel je koopt een nieuw systeem (met een P4), en je wil daar een linux distro op installeren die nog een kernel heeft die de P4 niet kent (het installatieproces heb ik het nu over), op dat moment kan je het wel vergeten, behalve dan als je die latere opmerking hieronder gebruikt.

[Verwijderd]

wat heeft dat met stabiliteit te maken? jij vindt dus niet dat het zo hoort dat linux je de optie geeft om bv. voor P3 te kiezen in zo'n geval, maar dat hij er vanuit moet gaan dat je het toch niet weet en dat ie dan maar helemaal bruut moet weigeren? nee okay, dat is logica... en nogmaals, stabiliteit?? dat raakt kant noch wal...
is vanuit een professioneel oogpunt ook niet zo ideaal lijkt mij trouwens... profileert linux zich niet meer als een server os dan als desktop os? en zoja, is het dan logisch dat hij hard weigert op nieuwe cpu's, waarvan het aannemelijker is dat ze in servers/bij bedrijven zitten dan in jan en alleman zn desktop pc?

[The Noid]

Hij weigert omdat Intel een sprong heeft gemaakt in de nummering. Als Intel gewoon het volgende nummertje had gebruikt was Linux er van uitgegaan dat alle PIII dingen wel werkten. Omdat Intel dus een sprong hebben gemaakt wordt er dus vanuit gegaan dat deze cpu NIET backwards compatibel is, DUS weigert Linux.

Hieruit kunnen we wel concluderen dat Intel nog wat nieuwe cputjes in de P3 reeks gepland heeft staan...

[Ralph Smeets]

Linux staat bekent als zijnde stabiel. Dwz, het is bijna onmogelijk Linux te laten crashen. Elke truuk om Linux stabieler te maken wordt uiteraard gebruikt en het maken van kleine aanpassingen in de kernel aan de hand van de CPUID hoort daarbij. Enkele Linux distributies hebben deze aanpassingen al ingebouwd.

De P4 is helemaal niet op de server markt gericht, daar hij SMP niet ondersteund. De P4 is gericht op de workstation markt. Voor de server markt voldoet 'n Xenon machine nog steeds. Servers moeten namelijk veel dingen in paralel doen. En dan werken twee of meer tragere CPUs in combinatie met 'n goede SMP chipset (lees serverworks) nog steeds sneller dan een hele snelle CPU!

Bedrijven die 'n nieuwe server kopen willen daarnaast ook schaalbaarheid. Dat betekent dat ze automatisch terecht komen bij 'n machine waarin men veel PCI 64 bits busmaster kaarten kwijt kan, veel zelf-corigerend geheugen en extra processoren kan plaatsen. Dus kom je vanzelf weer uit op de bekende Xenon processor!

[flipm0]

Uhm...een Xeon bedoel je?

[BasHouse]

No problem. Gewoon nog effe wachten en de update downloaden, of overstappen op Red Hat 7.

[Verwijderd]

Zoals de echte tweakers al gezien hebben is kernel 2.2.18 net uitgekomen, waar de pentium 4 weer correct gesupport wordt, en tevens is de support voor CPU's die sneller dan 2GHz lopen verbeterd.

[mvds]

Die CPUID is nodig om te bepalen welke instructies er wel en welke niet naar de CPU gestuurd mogen worden. Het is gewoon om de CPU te indentificeren. Vandaar ook de naam CPU-ID (cpu identification)

[flymuts]

Je hoeft helemaal niet te wachten, SuSE 7.0 had op Mon Dec 11 11:46:00 de patch al klaar staan.

[reapher]

Toch vindt ik het weer leuk om te horen van mensen die absoluut linux aanhangers zijn! "het is geen bug van linux het is een fout van intel enz" ik vindt het wel een minpuntje van linux! immers windows instaleerd wel fijn, dat is een plus puntje van windows. Ja ja ik weet het het is makkelijk te fixen met linux. Maar daat gaat het nu dus niet om, het feit ligt er het werkt niet. En als linux echt zo goed is kon hij wel zien dat het geen alpha of andere cpu is maar een x86(zeg ik dat zo goed?) O en over de mensen die zeggen kijk intel is niet stabiel das ook flauwekull want met de duron en TB waren er ook problemen in oude linux distro's.

[Verwijderd]

In september 1999 vondt win98 mijn gloed nieuwe Athlon (en alle andere gloed nieuwe hardware) niet zo leuk hoor. Elke 15 minuten weer een leuk blauw schermpje. MSIE 5 installeren bleek toen de oplossing.
(what ff, sinds wanneer fix een browser eigenlijk bugs in andere onderdelen van het os ??)
Win95 snapte niks van CPUID, een AMD K6 herkende die niet, geen probleem bij het installeren van win95, maar wel bij het installeren van andere software die gewoon de CPU info van de windows registry haalde.

[reapher]

ja hallo beetje vage opmerkingen he!!!! die blauwe schermen heeft iedereen met windows ook met IE4 ik heb er zelf ook genoeg last mee gehad zowel intel als amd.

en welke programma's instaleren dan niet heb hier ook win95 draaien op een duron en ik heb echt nog nooit probs gehad

[Verwijderd]

Ach, de hele discussie is eigenlijk - althans momenteel - meer van academische waarde en zal dat ook blijven zolang de P4 toch onbetaalbaar blijft voor sterfelijke zielen.
En dan nog: 't zal allemaal echt wel geregeld worden voordat ik een P4 koop

[Verwijderd]

Zoals het hoort in de Linux wereld is het nu al weer gefixed, kernel 2.2.18 is uit en daarin is het probleem opgelost.

[TheDuke]

Zoals het hoort in de Windows wereld werkte het op Windows al meteen

[ oftewel: zit niet van die idiote uitspraken te doen olivier ]

[Verwijderd]

TheDuke: dat is maar de vraag, dwz het werkt wel, maar of het foutloos werkt? WindowsME heeft een bug waardoor op snelle computers (lees P4) de HD al uit wordt geschakeld voordat de cash is weggeschreven. (is btw een patch voor).

[Jelmer]

goh, wat een wereld nieuws zeg! Dit probleem doet zich nl ook voor als je RedHat 6.2 en lager op die nieuwe AMD procs draait (Duron en TB). Simpel ff nieuwe kernel of patch (als het probleem eenmaal bekend is, is er zeer snel ook al wel een patch beschikbaar) downloaden en toepassen op de kernel source, recompilen en klaar.

[looskuh]

Geen flamebait verder, maar ik hoor wel eens het gerucht van intel - lovers dat ze geen AMD zouden nemen omdat die incompatible zou zijn met van alles en nog wat. Ach, heb ik er weer even een tegenargument bij

[doc]

Suse heeft al een patch beschikbaar gesteld!

ftp://ftp.suse.com/pub/suse/i386/update/7.0/kernel/pentium4/

Wie heeft er nog een p4 bord voor me over?