[OpenBSD] Hangt bij eerste boot op een leeg systeem.

[Surfer]

Ik heb van de week een wat oudere P II 350 onder het stof vandaan getrokken, voorzien van 256 Mb geheugen, en weer een beetje opgelapt.
De bedoeling is dat het een testmachinetje voor OpenBSD wordt.

Ik wilde er dus OpenBSD opzetten op de manier waarop ik dat altijd doe --> floppy35.fs maken met ntrw op mijn Win2000 machine, ervan booten, en verwijzen naar een intern FTP servertje waar de release opstaat. Normaal gat dat altijd prima.

Maar bij deze PC gaat het iets anders: Als ik boot van de diskette, dan wordt de kernel netjes van floppy gelezen en geprobeerd te starten. Daar blijft ie hangen en zie je alleen maar het volgende:

code:

OpenBSD 3.5 (RAMDISK #161: Mon mar 29 12:53:24 MST 2004
[e-mail]: /usr/src/sys/arch/i386/compile/RAMDISK
cpu0: Intel Pentium II ("GenuineIntel" 686-Class, 512 KB L2 cache)

En daar stopt ie. Het is ook al gebeurd dat ie niet stopt, maar reboot bij deze regel.

Ik heb geprobeerd met een OpenBSD 3.4 diskje te starten, exact hetzelfde verschijnsel. Verschillende floppies gebruikt, no dice.
Als ik echter van een Debian Woody CDtje opstart, en de vanilla kernel kies, dan loopt ie perfect door. Ook Windows lijkt allemaal goed te gaan (Windows 2000 CDtje erin, opstarten totdat setup gestart is). Ook Memtest86 3.1 vindt geen problemen na een dagje draaien.

Ik heb al geprobeerd te googlen, maar als ik zoek op "openbsd hangs cpu0" dan krijg ik wel allemaal dmesg's te zien, maar geen enkele die stopt bij cpu0.
Ideas anyone?

[Wilke]

Hmmm, interessant.

Bij de dmesg's die je vind met google, wat is dan de regel die gewoonlijk hierna komt? bv. herkenning van de harddisks?

Kans is natuurlijk groot dat het aan iets ligt wat hierna zou moeten gebeuren, vandaar deze vraag.

Als al het andere niet lukt: trek alles los behalve videokaart, harddisk en floppy drive, en probeer het dan weer. Wie weet helpt tweaken met BIOS-instellingen als 'plug&play OS installed' en handmatige toewijzingen van IRQ's aan/uit zetten (wat zit er verder voor hardware in)?

[Surfer]

Ik had inderdaad ook al gekeken naar wat daarna hoort te komen, maar er moet nog iets gebeuren met cpu0:

Stukje dmesg van een andere OBSD (3.2) machine uit mijn testomgeving:

code:

OpenBSD 3.2 (GENERIC) #0: Mon Apr 14 14:50:45 CEST 2003
    [e-mail]:/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium III (Coppermine) ("GenuineIntel" 686-class, 128KB L2 cache) 852 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SYS,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SIMD
real mem  = 117010432 (114268K)
avail mem = 102793216 (100384K)
using 1453 buffers containing 5951488 bytes (5812K) of memory

En van een 3.5 kernel zoals gevonden in Google Groups:

code:

cpu0: Intel(R) Xeon(TM) CPU 2.80GHz ("GenuineIntel" 686-class) 2.80 GHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,SBF,CNXT-ID
real mem  = 1073065984 (1047916K)
avail mem = 989691904 (966496K)
using 4278 buffers containing 53755904 bytes (52496K) of memory

Ik heb ook al ACPI uitgezet in de BIOS (kon me wat posts herinneren van wat Linux distro's die daar weleens problemen mee hebben, ik kan het altijd proberen), maar dat werkt ook niet. een of andere CPU Turbo mode uitgezet in de BIOS, werkt ook niet. Zal even verder bladeren door de BIOS en evt wat hardware eruit halen. Niet dat er veel in zit. Twee netwerkkaartjes, 2 harde schijven en een videokaart.

[Wilke]

Hee? Het lijkt dan alsof hij niet kan bepalen welke instructies de CPU ondersteunt, of dat de CPU of de check crasht tijdens het uitvoeren.

Da's wel vrij apart, nog niet eerder gezien. Nou heb ik vrijwel 0,0 ervaring met OpenBSD (heb het 1 keer geinstalleerd en dat is alweer jaren geleden), dus waar je verder naar zou kunnen kijken weet ik zo ook niet.

Ik zie btw. niet staan op hoeveel MHz die P2 draait, in tegenstelling tot de andere dmesg's die dit wel weergeven. Enig idee hoe dat komt?

De machine is toch niet 'per ongeluk' overgeklokt bij voorbeeld? Wat voor mobo zit er in, wie weet zegt dat iemand nog iets. Zal wel een of ander i440-BX bordje zijn. Als je de moed verder opgeeft, misschien helpt een BIOS-update iets

[Surfer]

Hmmz, nieuwe informatie:

Ik heb net zo'n beetje alles uit de PC gehaald wat er uit te halen valt. Er zit nu alleen nog maar een CPU, Mem, videokaart en een FDD in. Nu stopt ie weer op hetzelfde punt, maar wel met meer informatie:

code:

OpenBSD 3.5 (RAMDISK #161: Mon mar 29 12:53:24 MST 2004
[e-mail]: /usr/src/sys/arch/i386/compile/RAMDISK
cpu0: Intel Pentium II ("GenuineIntel" 686-Class, 512 KB L2 cache)

fatal priviledged instruction fault in supervisor mode
trap type 0 code 0 eip d01f7c3f cs 8 eflags 240 cr2 00 cpl0 
panic traptype 0, code=0, pc=d01f723f

overtypfouten voorbehouden, ik schrijf niet zo netjes

Ik ga eens kijken of ik een andere CPU heb liggen die in die socket past.

[Wilke]

Misschien toch wat ik zei dus, hij kan ws. niet bepalen welke features/instructies de CPU ondersteunt. Zou de CPU dan stuk zijn (da's echt zeldzaam bij mijn weten!) of ligt het aan OpenBSD, da's natuurlijk de vraag. Mobo kan het probleem mogelijk ook veroorzaken?

[Zwerver]

Hier staat wel iets over die fout, maar dat gaat niet zozeer over de Pii als wel over een look-a-like

[Surfer]

Het lijkt niet aan de CPU te liggen. Ik heb de PII 350 vervangen voor een Celeron 300, alles ingesteld in de BIOS en gechecked.
Als ik dan opstart met de OpenBSD flop, dan krijg ik weer precies hetzelfde probleem.

Dan inderdaad maar even kijken voor een BIOS update voor dat bord, blijkt er een Tandex Platinum II BD in te liggen. Wat dat dan voor merk is En er is geen website meer die iets weet van Tandex, en alles wat ooit Tandex was op het web, is nu een "domain for sale" geworden. Dus ik heb alle bruikbare spullen maar apart gelegd, en het mainboard in de afvalbak gegooid. Een beetje rommelen met oude PCtjes is leuk, maar het mag niet teveel tijd gaan kosten, zeker niet overdag op mijn werk...

Maandag krijg ik gelukkig mijn "normale" testdoos weer terug, waarin alles werkt, en met een trippleboot naar Win2K, Fedora 2, en OBSD 3.5.

Case Closed dus

P.S --> Zwerver: Het is inderdaad dezelfde fout, maar inderdaad op een ander type CPU, en in de April 1997 snapshot of i386 port Wellicht werkt het hoor, maar ik heb nu niet zo'n zin meer om het te proberen

[ Voor 13% gewijzigd door Surfer op 14-10-2004 14:27 ]

[TGEN]

Hmm, ik denk dat er ergens contactjes niet goed contact maakten, bijvoorbeeld het geheugen. Maar aangezien je t bordje al naar /dev/null verwezen ehbt, helaas .

[Wilke]

Hoe verklaar je dan dat memtest86 het wel een dag uithoud zonder fouten?

Vaag, gaar, no-name mobo, dat zal het vast zijn...maar goed, nu zullen we het idd nooit weten

[_JGC_]

Kan zijn dat er een bug in de microcode van dat bord zn BIOS zit. Ik heb zelf een routertje met een PC Chips M810LR bord met een duron 700. Toen ik toevallig nog een duron 1200 had liggen, bootte dat bord gewoon met die CPU. Linux bootte, werkte allemaal redelijk, totdat het filesystem flink werd aangesproken: grote hanger.

Vervolgens reset, rebooten in single user mode en filesystem check. Halverwege de check ook weer hangen
nog 3-4x geprobeerd, uiteindelijk L1 en L2 cache maar eens uitgezet: probleem opgelost, systeem alleen nog slomer dan een 386SX-25 met 2MB geheugen en een 40MB RLL schijf

Bleek dat dat moederbord geen support had voor die CPU, registers in de Duron werden niet goed geset waardoor de cache lockups en geheugencorrupties veroorzaakten. Duron 700 er weer in en werken maar weer, die Duron 1200 werkt nu al weer een paar maandjes goed in een ander moederbord.

[Surfer]

Wilke schreef op 15 oktober 2004 @ 00:50:
Vaag, gaar, no-name mobo, dat zal het vast zijn...maar goed, nu zullen we het idd nooit weten

Als je er écht achter wilt komen kun je het boardje wel krijgen hoor. Hij ligt nog niet fysiek in de trashbin. Hij ligt nu ergens bovenop, achterin op een plank in het rommelhok. Als je een keer een uurtje (of wat) nix te doen hebt misschien?