Hozzászólások
Sziasztok!
A $SUBJECT-ben szereplő gépre próbálom felküzdeni a FreeBSD-t. Most épp egy 5.3BETA7-re frissített 5.2.1-essel próbálkozom, az 5.3 fel sem ment, már az installnál elhalt. A gép változó időközönként egyszerűen elhal, ezzel az üzenettel:
[code:1:8777643455]
panic: initiate_write_inodeblock_ufs2: already started
cpuid = 0
boot() called on cpu#0
Uptime: 57m52s
Cannot dump. No dump device defined.
Shutting down ACPI
Automatic reboot in 15 seconds...
[/code:1:8777643455]
Amire gyanakszom az az ACPI, de anélkül meg nincs HyperThreading, tehát jó lenne bekapcsolva hagyni.
A gépben most 1db 3.06GHz-s Xeon CPU van, de érkezik bele a másik is.
Ami később futna rajta: mail/web/ftp.
Van valakinek tippje, tapasztalalta ezzel kapcsolatban?
Köszi előre is!
MantaRay
- A hozzászóláshoz be kell jelentkezni
[quote:6ca39a5c6c="MantaRay"]
Van valakinek tippje, tapasztalalta ezzel kapcsolatban?
Köszi előre is!
MantaRay
Igen van. Sajnos nem jok. A mult honapban telepitettem egy quad IBM szerverre FreeBSD-t. Nekem telepult, majd random rebootok jottek. Max uptime amit sikerult elerni, az olyan 4-5 ora volt. Ja en meg BETA3-mal probaltam...
- A hozzászóláshoz be kell jelentkezni
[quote:5bb0892962="trey"]
Igen van. Sajnos nem jok. A mult honapban telepitettem egy quad IBM szerverre FreeBSD-t. Nekem telepult, majd random rebootok jottek. Max uptime amit sikerult elerni, az olyan 4-5 ora volt.
Ez nem hangzik valami bíztatóan... :(
Ezek szerint ne erőltessem a BSD-t, próbáljak inkább mást, vagy nem OS-függő a probléma?
Próbálok még egy memtestet futtatni, de sajnos kétlem, hogy ott lenne a baj.
Tesztelem kikapcsolt ACPI-val is, de hát ugye az nem kevés lemondással jár...
MantaRay
- A hozzászóláshoz be kell jelentkezni
[quote:e514e7948c="MantaRay"]A $SUBJECT-ben szereplő gépre próbálom felküzdeni a FreeBSD-t. Most épp egy 5.3BETA7-re frissített 5.2.1-essel próbálkozom, az 5.3 fel sem ment, már az installnál elhalt. A gép változó időközönként egyszerűen elhal, ezzel az üzenettel:
[code:1:e514e7948c]
panic: initiate_write_inodeblock_ufs2: already started
cpuid = 0
boot() called on cpu#0
Uptime: 57m52s
Cannot dump. No dump device defined.
Shutting down ACPI
Automatic reboot in 15 seconds...
[/code:1:e514e7948c]
Amire gyanakszom az az ACPI, de anélkül meg nincs HyperThreading, tehát jó lenne bekapcsolva hagyni.
A gépben most 1db 3.06GHz-s Xeon CPU van, de érkezik bele a másik is.
Ami később futna rajta: mail/web/ftp.
debug kernel, /etc/rc.conf -ba (ertelemszeruen ofkoz)
dumpdev="/dev/da0s1b"
dumpdir="/var/crash"
aztan send-pr a crash traceback-kel egyutt.
- A hozzászóláshoz be kell jelentkezni
Gyönyörű, most már ACPI nélkül is fagy. :x Most fut egy memtest, hátha...
Szerintetek érdemes megpróbálni pl. Debiannal?
Üdv,
MantaRay
- A hozzászóláshoz be kell jelentkezni
[quote:cccd635865="MantaRay"]Gyönyörű, most már ACPI nélkül is fagy. :x Most fut egy memtest, hátha...
Szerintetek érdemes megpróbálni pl. Debiannal?
Üdv,
MantaRay
Ha memoria hibara gyanakszol, akkor azt nem memtest-tel kene ilyen gepen nezni. Azert van a szerver management, hogy jelezze, ha az ECC mar bithibat javitott. En azzal nezegetnem inkabb...
- A hozzászóláshoz be kell jelentkezni
[quote:dc1b0fbf02="MantaRay"]Sziasztok!
A $SUBJECT-ben szereplő gépre próbálom felküzdeni a FreeBSD-t. Most épp egy 5.3BETA7-re frissített 5.2.1-essel próbálkozom, az 5.3 fel sem ment, már az installnál elhalt. A gép változó időközönként egyszerűen elhal, ezzel az üzenettel:
[code:1:dc1b0fbf02]
panic: initiate_write_inodeblock_ufs2: already started
cpuid = 0
boot() called on cpu#0
Uptime: 57m52s
Cannot dump. No dump device defined.
Shutting down ACPI
Automatic reboot in 15 seconds...
[/code:1:dc1b0fbf02]
Amire gyanakszom az az ACPI, de anélkül meg nincs HyperThreading, tehát jó lenne bekapcsolva hagyni.
A gépben most 1db 3.06GHz-s Xeon CPU van, de érkezik bele a másik is.
Ami később futna rajta: mail/web/ftp.
Van valakinek tippje, tapasztalalta ezzel kapcsolatban?
Köszi előre is!
MantaRay
Huje kerdes: 4.10-el probaltad? Ha IBM ServeRAID van, akkor nagyon jo esellyel el fog halni, mert azt nem igazan szereti a BSD. Linux ellenben gyonoruen fut, mondjuk egy Gentoo. :)
- A hozzászóláshoz be kell jelentkezni
[quote:1928240ddd="andrej_"]Huje kerdes: 4.10-el probaltad? Ha IBM ServeRAID van, akkor nagyon jo esellyel el fog halni, mert azt nem igazan szereti a BSD. Linux ellenben gyonoruen fut, mondjuk egy Gentoo. :)
(azon tunodok, vajon hany percen belul jon egy olyan hozzaszolas valakitol, hogy "MERNEM DEBIAN?!?" :roll:)
- A hozzászóláshoz be kell jelentkezni
Egyebkent a multkor szorakozasbol megszamoltam a -current listan a BETA-kkal kapcsolatos panic / install problema jelenteseket, es egy borzaszto szamot kaptam. En attol felek, hogy ez a 5.x sorozat stabilla nyilvanitasa varhatna meg. Azt nem mondom, hogy elkapkodott, mert annak idejen mar egy evet csuszott az 5.x sorozat :-). Viszont az, hogy a BETA4 mar ugy jott ki, hogy az alapertelmezett process scheduler ismet a 4BSD az ULE helyett... hat nem tudom. Ne legyen igazam...
- A hozzászóláshoz be kell jelentkezni
Szia.
Nem egeszen a temahoz tartozik de nemregen egy xServer 225 -el es Woody -val volt gond es a tunetek veletlen lefagyasok voltak. En is hardverre gyanakodtam. Vegul is ugy nez ki hogy a halokartya volt a ludas /integralt broadcom netXtreme 5700 volt rajta/ jobban mondva a gyari drivere volt bugos.
Gondolom nalad nem ez a problema de proba szerencse....
Errol a kalvariarol reszleteket a Hálózatu csatolok /NIC/ topicban olvashatsz Broadcom 5700 okozhat-e kernel panic -ot? cimmel.
- A hozzászóláshoz be kell jelentkezni
Annyit tudok ajanlani, hogy DEBUG_LOCKS -val fordits egy debug kernelt. Majd vedd fel a kapcsolatot a fejlesztokkel vagy kuldj PR -t.
- A hozzászóláshoz be kell jelentkezni
[quote:b0c9264bd0="Nosferatu"]Szia.
Nem egeszen a temahoz tartozik de nemregen egy xServer 225 -el es Woody -val volt gond es a tunetek veletlen lefagyasok voltak. En is hardverre gyanakodtam. Vegul is ugy nez ki hogy a halokartya volt a ludas /integralt broadcom netXtreme 5700 volt rajta/ jobban mondva a gyari drivere volt bugos.
Gondolom nalad nem ez a problema de proba szerencse....
Errol a kalvariarol reszleteket a Hálózatu csatolok /NIC/ topicban olvashatsz Broadcom 5700 okozhat-e kernel panic -ot? cimmel.
hehe, na ez egyre viccesebb. en egy xserver 200-at latok mostanaban random rebootolni (suse 8.2, kenyszerbol), meg egy ugyanilyet win2k-val (szinten kenyszer). ugyanakkor jopar regebbi netfinity (3500, 4500R, 5000, 5500, 6000R, sot, a BSD-s tesztben szereplo 7000 M20-al teljesen megegyezo) van/volt a kezem alatt, linux/w2k/w2k3-at futtatva, ezekkel semmi baj, szanaszejjel terhelve sem (nemelyik kapott csunyan pedig).
a 200-ban igy hirtelen nemtom milyen NIC van, de broadcom chipes 3com rezes gigabit kartyaval mar korabban szivtam linux alatt (2k alatt ua. kartya 2-3 evig 7/24-ben gond nelkul ment, woodyval meg 1-2 ora folyamatos uzem utan szejjelborult)...
- A hozzászóláshoz be kell jelentkezni
[quote:5fc595c6f7="zsirfeka"][quote:5fc595c6f7="Nosferatu"]Szia.
Nem egeszen a temahoz tartozik de nemregen egy xServer 225 -el es Woody -val volt gond es a tunetek veletlen lefagyasok voltak. En is hardverre gyanakodtam. Vegul is ugy nez ki hogy a halokartya volt a ludas /integralt broadcom netXtreme 5700 volt rajta/ jobban mondva a gyari drivere volt bugos.
Gondolom nalad nem ez a problema de proba szerencse....
Errol a kalvariarol reszleteket a Hálózatu csatolok /NIC/ topicban olvashatsz Broadcom 5700 okozhat-e kernel panic -ot? cimmel.
hehe, na ez egyre viccesebb. en egy xserver 200-at latok mostanaban random rebootolni (suse 8.2, kenyszerbol), meg egy ugyanilyet win2k-val (szinten kenyszer). ugyanakkor jopar regebbi netfinity (3500, 4500R, 5000, 5500, 6000R, sot, a BSD-s tesztben szereplo 7000 M20-al teljesen megegyezo) van/volt a kezem alatt, linux/w2k/w2k3-at futtatva, ezekkel semmi baj, szanaszejjel terhelve sem (nemelyik kapott csunyan pedig).
a 200-ban igy hirtelen nemtom milyen NIC van, de broadcom chipes 3com rezes gigabit kartyaval mar korabban szivtam linux alatt (2k alatt ua. kartya 2-3 evig 7/24-ben gond nelkul ment, woodyval meg 1-2 ora folyamatos uzem utan szejjelborult)...
A 200-ban nem az a gond. Allitolag a CPU kondik szarok benne. Szemrevetelezessel eszlelheto a hiba (ki vannak pukkanva). Allitolag szeriahiba, az IBM szo nelkul csereli garban. Ezt itt olvastama forumban valakitol, de lehet benne valami, mert a 200-asbol en sajat szemmel lattam rebootolgatni legalabb 3-4-et.
Persze azt tegyuk hozza, hogy ezek a gepek (200-as) marha messze vannak a szervertol...
- A hozzászóláshoz be kell jelentkezni
[quote:029fa417c6="zsirfeka"](azon tunodok, vajon hany percen belul jon egy olyan hozzaszolas valakitol, hogy "MERNEM DEBIAN?!?" :roll:)
Nem tudom miért tűnődsz rajta MantaRay harmadik hozzászólásában már kérdezte...
- A hozzászóláshoz be kell jelentkezni
[quote:9c92939b4f="thuglife"]Annyit tudok ajanlani, hogy DEBUG_LOCKS -val fordits egy debug kernelt. Majd vedd fel a kapcsolatot a fejlesztokkel vagy kuldj PR -t.
Ooo, az osszes BETA kiadas debug kernellel van forditva :-D
- A hozzászóláshoz be kell jelentkezni
[quote:dd6f994ac7="trey"]A 200-ban nem az a gond. Allitolag a CPU kondik szarok benne. Szemrevetelezessel eszlelheto a hiba (ki vannak pukkanva). Allitolag szeriahiba, az IBM szo nelkul csereli garban. Ezt itt olvastama forumban valakitol, de lehet benne valami, mert a 200-asbol en sajat szemmel lattam rebootolgatni legalabb 3-4-et.
heh, ez kivalo. na majd megnezem, kosz a tippet.
[quote:dd6f994ac7="trey"]Persze azt tegyuk hozza, hogy ezek a gepek (200-as) marha messze vannak a szervertol...
de azer' joval koelebb mint a titkarno kidobott gepebol osszehekkelt, "birja az"-szerver
- A hozzászóláshoz be kell jelentkezni
[quote:0321cfcfe1="zsirfeka"][quote:0321cfcfe1="trey"]A 200-ban nem az a gond. Allitolag a CPU kondik szarok benne. Szemrevetelezessel eszlelheto a hiba (ki vannak pukkanva). Allitolag szeriahiba, az IBM szo nelkul csereli garban. Ezt itt olvastama forumban valakitol, de lehet benne valami, mert a 200-asbol en sajat szemmel lattam rebootolgatni legalabb 3-4-et.
heh, ez kivalo. na majd megnezem, kosz a tippet.
[quote:0321cfcfe1="trey"]Persze azt tegyuk hozza, hogy ezek a gepek (200-as) marha messze vannak a szervertol...
de azer' joval koelebb mint a titkarno kidobott gepebol osszehekkelt, "birja az"-szerver
Igen annal jobb. De az en felfogasomban az nem szerver, amiben integralt hangkartya van :-D Most fejbol nem emlekszem, hogy a 200-as ban van-e, de valami ilyen kicsi szutyokban van az tuti.
- A hozzászóláshoz be kell jelentkezni
[quote:47fc3e9d04="trey"]Igen annal jobb. De az en felfogasomban az nem szerver, amiben integralt hangkartya van :-D Most fejbol nem emlekszem, hogy a 200-as ban van-e, de valami ilyen kicsi szutyokban van az tuti.
igen, jogos :)
- A hozzászóláshoz be kell jelentkezni
[quote:b326fd7a03="trey"][quote:b326fd7a03="thuglife"]Annyit tudok ajanlani, hogy DEBUG_LOCKS -val fordits egy debug kernelt. Majd vedd fel a kapcsolatot a fejlesztokkel vagy kuldj PR -t.
Ooo, az osszes BETA kiadas debug kernellel van forditva :-D
Szivem, ne legyel már ilyen korlátozott! :lol: Lehet hogy nem GENERIC kernellt probalgat az emberunk. Sot az is lehet hogy DEBUG_LOCKS nincs benne default. De ezt nem tudom.
- A hozzászóláshoz be kell jelentkezni
[quote:f4bc9011bc="thuglife"]Szivem, ne legyel már ilyen korlátozott! :lol: Lehet hogy nem GENERIC kernellt probalgat az emberunk. Sot az is lehet hogy DEBUG_LOCKS nincs benne default. De ezt nem tudom.
:) Valóban nem GENERIC, muszáj volt 1-2 apróságot még beletennem. No meg frissítve lett a stuff 5.2.1-ről 5.3BETA-ra.
Mivel sajnos elég húzos a határideje a dolognak, nem tudom megvárni, hogy javítsák a hibát (már ha a BSD sz*rakodik), megpróbálom Gentooval és Debiannal is, aztán amelyik jobban teljesít, az nyer. :)
Mindhárom OS-t használom itt szervereken is, desktopon is, nincsenek előítéleteim. :) Alapból BSD-t szerettem volna, SSL/tűzfal/traffic shaper szempontokból valahogy nekem jobban bevált, de ha nem megy, akkor marad a linux. Valamelyik. :)
Köszi a hozzászólásokat mindenkinek, ha (stabil) működésre tudom bírni a gépet, jelzek!
Üdv,
MantaRay
- A hozzászóláshoz be kell jelentkezni
[quote:b2598004bc="MantaRay"][quote:b2598004bc="thuglife"]Szivem, ne legyel már ilyen korlátozott! :lol: Lehet hogy nem GENERIC kernellt probalgat az emberunk. Sot az is lehet hogy DEBUG_LOCKS nincs benne default. De ezt nem tudom.
:) Valóban nem GENERIC, muszáj volt 1-2 apróságot még beletennem. No meg frissítve lett a stuff 5.2.1-ről 5.3BETA-ra.
Mivel sajnos elég húzos a határideje a dolognak, nem tudom megvárni, hogy javítsák a hibát (már ha a BSD sz*rakodik), megpróbálom Gentooval és Debiannal is, aztán amelyik jobban teljesít, az nyer. :)
Mindhárom OS-t használom itt szervereken is, desktopon is, nincsenek előítéleteim. :) Alapból BSD-t szerettem volna, SSL/tűzfal/traffic shaper szempontokból valahogy nekem jobban bevált, de ha nem megy, akkor marad a linux. Valamelyik. :)
Köszi a hozzászólásokat mindenkinek, ha (stabil) működésre tudom bírni a gépet, jelzek!
Üdv,
MantaRay
Akkor pont itt lenne az ideje egy GENERIC-kel is megprobalni, nemde?
- A hozzászóláshoz be kell jelentkezni
Beleneztem a skull altal is emlitett gepekbe es valoban itt is csunyan neztek ki a kondik. A windozos gepen teljesen szejjel voltak, az par orat bir max, a linuxos bir par napot altalaban de azon meg csak most kezdenek szetnyilni a kondik :)
- A hozzászóláshoz be kell jelentkezni