Netzteil defekt oder unterdimensioniert?

mr44er

mr44er

moderater Moderator
Teammitglied
Moin, mal wieder Absturzprobleme. Dh. der Server ist heute Morgen kommentarlos neu gestartet.
Zur betreffenden Zeit nichts unter /var/crash, ipmitool sel list oder dmesg

memtest läuft problemlos durch, Platten sind bei Zugriff selten über 40°C

Es passierte, während ich eine große Datenmenge von ihm kopierte (50Gb). Schon länger nicht mehr passiert, dass die Kiste bei längeren Kopiervorgängen wegsemmelte.

Ich habe das Netzteil daher in Verdacht. Entweder defekt oder unterdimensioniert (485W). Es wurde wegen Abstürzen dieser Art bisher ALLES (CPU, Board, RAM-Riegel, Festplatten, sogar neue Kühlpaste für CPU und SAS-Controller) getauscht. Nur eben noch nicht das NT, daher meine Vermutung.

Die Rechnung der Dimensionierung:

11 Watt pro SAS-Platte laut specs (8 Stück mit 15 Watt gerechnet) = 120
3x Sata gemischt (3 Stück mit 15 Watt gerechnet) = 45
CPU 95W TDP (nehm ich mal so als Wert)
6 Lüfter (mit guten 5W gerechnet) = 30
2 PCI-E Karten (1x DUALNIC, 1x SAS-Controller) = keine Ahnung, gönnen wir den beiden mal gute 20W zusammen

Bleiben fürs Mainboard und für einzelne Mehrleistung der Komponenten immer noch 175W übrig.

max. gemessener Stromverbrauch an der Dose 260W


Ich hab jetzt mal die Kiste offen ans dickere Netzteil gehängt wie auf dem Foto.

Es fällt mir noch ein, dass ich vielleicht die Backplane falsch verstromt habe. Wie schließt man die Backplane korrekt an? Wie im IST-Zustand oder eins der anderen Beispiele? (bin kein gimpmeister :p )
 

Anhänge

  • 1.webp
    1.webp
    53,3 KB · Aufrufe: 477
  • 2.webp
    2.webp
    79,7 KB · Aufrufe: 522
  • 3.webp
    3.webp
    82,2 KB · Aufrufe: 541
  • 4.webp
    4.webp
    139,8 KB · Aufrufe: 529
  • 5.webp
    5.webp
    12,3 KB · Aufrufe: 502
  • 6.webp
    6.webp
    8,3 KB · Aufrufe: 468
  • 7.webp
    7.webp
    17,1 KB · Aufrufe: 504
Ein 485W Netzteil reicht absolut aus. Tatsächlich ist es eine Unsitte geworden Netzteile restlos überzudimensionieren, wodurch sie am unteren Ende des Lastbereichs betrieben werden wo sie vergleichsweise ineffizient sind. ABER die Sache ist, dass diese 485W erstmal absolut nichtssagend sind. Entscheidend ist, wie sich die 485W auf die einzelnen Schienen verteilen. Moderne Computer ziehen nämlich fast ihren gesamten Energiebedarf auf der 12V Schiene... Das alte Netzteil kann 32A auf einer kombinierten (also für alles genutzten) 12V Schiene liefern, das sind 12V*32A=384W. Das neue Netzteil sogar 12V*40A=480W. Das reicht. Ein weiterer Faktor sind Lastspitzen, die digital gesteuerten Spannungswandler moderner CPUs können in Mikrosekunden von fast Leerlauf auf Spitzenlast springen. Kommt das Netzteil nicht mit, gibt es einen Brownout durch Unterversorgung. Das kommt mit hochwertigen, neueren Netzteilen kaum vor, aber sehr wohl wenn man ältere Netzteile mit aktuellen Mainboards und CPUs kombiniert. So als Beispiel zeigt z.B. mein 2008 gekauftes Corsair-Netzteil im Desktop das Problem, wenn ich es mit einer Skylake-CPU kombiniere.
 
Top, die Erklärung. Also ernüchternde Glaskugel in Richtung, dass das alte NT hinüber ist? Dann weiß ich wenigstens, woran ich bin. :)
Den sog. Brownout kann ich mir bei einem Opteron aus 2011 nicht vorstellen.

Werde das dickere mal so laufen lassen, der Uptimerekord liegt jetzt bei nur zwei Wochen. :rolleyes:
 
Ja, bei einem alten Opteron kann man zu wenig Spannung durch zu schnell schaltende Spannungswandler wohl ausschließen. AMD war bis direkt vor Zen in Sachen Spannungsversorgung eher "rustikal". Dir wird nur übrig bleiben und weiter beobachten. Dass das Netzteil schuldig ist, ist zumindest nicht unwahrscheinlich.
 
So, eben ist die Kiste wieder weggeschmiert.

no suitable dump device was found konnte ich erhaschen beim nächsten boot

Physikalisch sind 32GB drin, pro ZFS-Platte jedoch nur 2GB swap.

Ich hab jetzt mal in rc.conf das so geändert:

Code: 
dumpdev="NO"
dumpdir="/var/crash"

Macht das, was ich will? 32GB sind jedenfalls noch frei unter /var/crash...
 
Man könnte ja auch einfach mal - unter Last - sich mir nen Oszi die Spannung ansehen und messen - und auch mal bis zum Crash schreiben! ... sofern man Zugriff auf passendes Equipment hat - wenn man natürlich nur „von früher, von Schule/Studium“ ein analoges Ein- oder Zweikanal 20MHz Oszi hat, macht es keinen Sinn;-)
 
Muss ich verneinen, habe ich nicht, kann ich nicht. :) Da die Kiste auch mit einem anderen Netzteil wegsemmelte....kann man auch das ausschließen.

Stürzte auch an einer anderen Steckdose im anderen Raum ab.


Ich hab gestern sogar noch verzweifelt die SATA-Kabel gegen nagelneue ausgewechselt und das DVD-Laufwerk abgezupft.



Nochmal zusammengefasst, was bisher getan wurde:

CPU wurde getauscht inkl. Paste (stresstest bestanden, lief lange)

Mainboard wurde getauscht (aktuellstes BIOS jeweils drauf)

Alle RAM-Riegel wurden getauscht (trotz erfolgreichem memtest, sind sogar auf der Kompatibilitätsliste vom Handbuch)

Alle Festplatten wurden getauscht

SAS-Controller wurde getauscht (sogar anderes Modell) (+Kühlpaste davon erneuert + Lüfter auf den Kühler montiert)

Zusätzliche Netzwerkkarte wurde mal ausgebaut, um auch die ausschließen zu können

Überall auf dem Board habe ich zusätzlich Lüfter auf die Kühlrippen montiert, alle Temperaturen im Traumbereich

ALLE Lüfter überprüft, laufen problemlos

Netzteil getauscht

ipmitool sel list -> leer
dmesg.today -> nichts sichtbar, in allen anderen Logs auch nichts zu den betreffenden Uhrzeiten

Das ganze Innenleben ist staubfrei/sauber.

Keine USB-Geräte dran

Abstürze mit und ohne geschlossenem Gehäuse

Aktuell fällt mir nichts mehr ein. Das ist die erste Kiste, die solche unauffindbaren Probleme bereitet.

Bevor ich jetzt noch die Backplane und die Kabel austausche (wie wahrscheinlich ist das überhaupt?) ....hat wer noch Ideen? :(


Der Kernel ist mit 'generic' und altq gebacken:
Code: 
options         ALTQ
options         ALTQ_CBQ        # Class Based Queuing (CBQ)
options         ALTQ_RED        # Random Early Detection (RED)
options         ALTQ_RIO        # RED In/Out
options         ALTQ_HFSC       # Hierarchical Packet Scheduler (HFSC)
options         ALTQ_PRIQ       # Priority Queuing (PRIQ)

Code: 
$ pkg info
apr-1.6.3.1.6.1_1              Apache Portability Library
argp-standalone-1.3_3          Standalone version of arguments parsing functions from GLIBC
autoconf-2.69_1                Automatically configure source code on many Un*x platforms
autoconf-wrapper-20131203      Wrapper script for GNU autoconf
automake-1.15.1                GNU Standards-compliant Makefile generator
automake-wrapper-20131203      Wrapper script for GNU automake
db5-5.3.28_6                   Oracle Berkeley DB, revision 5.3
devcpu-data-1.17               Intel and AMD CPUs microcode updates
dialog4ports-0.1.6             Console Interface to configure ports
dmidecode-3.1_1                Tool for dumping DMI (SMBIOS) contents in human-readable format
expat-2.2.5                    XML 1.0 parser written in C
ezjail-3.4.2                   Framework to easily create, manipulate, and run FreeBSD jails
freeipmi-1.5.7                 Library and tools to support IPMI-capable hardware
gdbm-1.13_1                    GNU database manager
gettext-runtime-0.19.8.1_1     GNU gettext runtime libraries and programs
gettext-tools-0.19.8.1         GNU gettext development and translation tools
gmake-4.2.1_2                  GNU version of 'make' utility
help2man-1.47.6                Automatically generating simple manual pages from program output
indexinfo-0.3.1                Utility to regenerate the GNU info page index
ipmitool-1.8.18_1              CLI to manage IPMI systems
isc-dhcp43-server-4.3.6P1      ISC Dynamic Host Configuration Protocol server
ldns-1.7.0_1                   Library for programs conforming to DNS RFCs and drafts
libevent-2.1.8_1               API for executing callback functions on events or timeouts
libffi-3.2.1_2                 Foreign Function Interface
libgcrypt-1.8.2                General purpose crypto library based on code used in GnuPG
libgpg-error-1.31              Common error values for all GnuPG components
liblz4-1.8.2,1                 LZ4 compression library, lossless and very fast
libtool-2.4.6                  Generic shared library support script
m4-1.4.18,1                    GNU M4
mpd5-5.8_3                     Multi-link PPP daemon based on netgraph(4)
p5-Authen-PAM-0.16_2           Perl interface to the PAM library
p5-IO-Tty-1.12_2               Flexible I/O Perl5 module that allows manipulation of pseudo-TTYs
p5-Locale-gettext-1.07         Message handling functions
p5-Net-SSLeay-1.85             Perl5 interface to SSL
perl5-5.26.2                   Practical Extraction and Report Language
pkg-1.10.5_1                   Package manager
pkgconf-1.4.2,1                Utility to help to configure compiler and linker flags
portmaster-3.19_12             Manage your ports without external databases or languages
py27-setuptools-39.2.0         Python packages installer
python27-2.7.15                Interpreted object-oriented programming language
readline-7.0.3_1               Library for editing command lines as they are typed
scons-3.0.1                    Build tool alternative to make
serf-1.3.9_3                   Serf HTTP client library
smartmontools-6.6_1            S.M.A.R.T. disk monitoring tools
spindown-0.4                   SCSI/firewire harddrive spindown daemon
sqlite3-3.23.1                 SQL database engine in a C library
squid-3.5.27_3                 HTTP Caching Proxy
stress-1.0.4                   Tool to impose load on and stress test Unix-like systems
subversion-1.10.0              Version control system
texinfo-6.5,1                  Typeset documentation system with multiple format output
unbound-1.7.1_1                Validating, recursive, and caching DNS resolver
utf8proc-2.1.0                 UTF-8 processing library
webmin-1.881                   Web-based interface for system administration for Unix

devcpu-data-1.17 Intel and AMD CPUs microcode updates -> ist auch ohne die updates abgestürzt
spindown-0.4 SCSI/firewire harddrive spindown daemon -> ist auch mit abgeschaltetem spindown, also dauerlaufenden Platten abgestürzt

loader.conf
Code: 
aesni_load="YES"
geom_eli_load="YES"
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
vfs.zfs.min_auto_ashift=12
zfs_load="YES"

###net/mpd5###
ng_ether_load="YES"
###net/mpd5###

###sysutils/ipmitool###
ipmi_load="YES"
###sysutils/ipmitool###

###benoetigt fuer apache24 in jail###
accf_http_load="YES"
###benoetigt fuer apache24 in jail###

rc.conf
Code: 
hostname="smain"
keymap="de"

###sysutils/devcpu-data###
microcode_update_enable="YES"
###sysutils/devcpu-data###

###cpu taktung###
powerd_enable="YES"
powerd_flags="-a adaptive -b adaptive -n adaptive"
###cpu taktung###

###sysutils/spindown fuer sata und sas###
spindown_enable="YES"
spindown_flags="-b -t 3600 -d da0 -d da1 -d da2 -d da3 -d da4 -d da5 -d da6 -d da7"
###sysutils/spindown fuer sata und sas###

###sysutils/smartmontools###
smartd_enable="YES"
###sysutils/smartmontools###

###ips physikalische netzwerkkarten###
ifconfig_em0="inet 192.168.100.5 netmask 255.255.255.0"
ifconfig_em1="inet 10.0.8.1 netmask 255.255.254.0"
ifconfig_em2="inet 10.0.6.1 netmask 255.255.254.0"
###ips physikalische netzwerkkarten###

###alias ips jails###
ifconfig_em1_alias0="inet 10.0.8.10 netmask 255.255.255.254" #jasterisk
ifconfig_em1_alias1="inet 10.0.8.11 netmask 255.255.255.254" #apachetest
###alias ips jails###

###sysutils/ezjail###
ezjail_enable="YES"
###sysutils/ezjail###

###net/mpd5###
mpd_enable="YES"
###net/mpd5###

###routing aktiviert###
gateway_enable="YES"
###routing aktiviert###

###firewall (pf) aktiviert###
pf_enable="YES"
pflog_enable="YES"
###firewall (pf) aktiviert###

###net/isc-dhcp43-server###
dhcpd_enable="YES"
dhcpd_ifaces="em1 em2"
###net/isc-dhcp43-server###

###dns/unbound###
unbound_enable="YES"
###dns/unbound###

###nfsserver###
rpcbind_enable="YES"
nfs_server_enable="YES"
mountd_flags="-r"
###nfsserver###

###www/squid###
squid_enable="YES"
###www/squid###

###sysutils/webmin###
webmin_enable="YES"
###sysutils/webmin###

sshd_enable="YES"
ntpd_enable="YES"

# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"
dumpdir="/var/crash"

zfs_enable="YES"
 
Zuletzt bearbeitet:
Tritt der Fehler wirklich nur bei größeren Plattenzugriffen auf?

Könnte evtl. mit der Spannungsversorgung etwas nicht stimmen, also z.B. ein lockeres Netzkabel an das jemand zum jew. Zeitraum gegenkommt, eine defekte vorgeschaltete USV o.ä.? Irgendwelche seltsamen Kriechspannungen?
 
Yamagi schrieb:
Du musst das dumpdev auf "AUTO" setzen.
Zum Vergrößern anklicken....
So hatte ich es, ich hab das erst geändert, als folgendes kam: no suitable dump device was found konnte ich erhaschen beim nächsten boot
Ich bin mir zu 99% sicher, dass ich den swap auch nicht verschlüsselt oder gespiegelt habe. (das setup weist ja darauf hin)
Das System habe ich u.a. auch deswegen nochmal neu aufgesetzt.

Habe auch gestern nach Absturz einen scrub laufen lassen.

Code: 
$ zpool status
  pool: tank
state: ONLINE
  scan: scrub repaired 0 in 1h49m with 0 errors on Tue May 15 15:57:17 2018
config:

    NAME                    STATE     READ WRITE CKSUM
    tank                    ONLINE       0     0     0
      raidz3-0              ONLINE       0     0     0
        label/K5GWGJVA-hd1  ONLINE       0     0     0
        label/K5GWGN5A-hd2  ONLINE       0     0     0
        label/K5GW31WA-hd3  ONLINE       0     0     0
        label/N4G2N9AY-hd4  ONLINE       0     0     0
        label/K5GWAZTA-hd5  ONLINE       0     0     0
        label/N4G1XV1K-hd6  ONLINE       0     0     0
        label/K5GW6SGA-hd7  ONLINE       0     0     0
        label/K5GWGL2A-hd8  ONLINE       0     0     0

errors: No known data errors

  pool: zroot
state: ONLINE
  scan: scrub repaired 0 in 0h14m with 0 errors on Thu Jun  7 23:27:00 2018
config:

    NAME            STATE     READ WRITE CKSUM
    zroot           ONLINE       0     0     0
      mirror-0      ONLINE       0     0     0
        ada0p3.eli  ONLINE       0     0     0
        ada1p3.eli  ONLINE       0     0     0
        ada2p3.eli  ONLINE       0     0     0

errors: No known data errors

CommanderZed schrieb:
Tritt der Fehler wirklich nur bei größeren Plattenzugriffen auf?

Könnte evtl. mit der Spannungsversorgung etwas nicht stimmen, also z.B. ein lockeres Netzkabel an das jemand zum jew. Zeitraum gegenkommt, eine defekte vorgeschaltete USV o.ä.? Irgendwelche seltsamen Kriechspannungen?
Zum Vergrößern anklicken....

Nein, das passierte auch mehrfach, als ich nichtmal zuhause war und das System tagelang vor sich hinidlete. Als es gestern passierte, war ich mit ssh auf dem Ding drauf und hab den apache24 in einer jail kompiliert. Die Sitzung auf meinem Arbeitspc blieb stehen, da konnte ich zumindest noch sehen, dass das fertig kompiliert und installiert wurde, ist dann ein paar Minuten später passiert. Also nichts mit zu heiß beim kompilieren und währenddessen abgestürzt.
Mehrfach stürzte er ab, während ich eine Filmdatei streamte oder was draufkopierte (ich hab erst meine alten Samsungs rausgeschmissen und dann HGST SATAs benutzt...wieder abgestürzt. daraufhin hab ich nagelneue SAS-Platten gekauft und als das immer noch passierte, hab ich noch nen anderen SAS-Controller getestet)
Die 3 Platten, die zroot bilden hatte ich auch schon testweise gewechselt...auch das System von einer einzelnen SATA-Platte gebootet...trotzdem Absturz.
Ein andermal gab es überhaupt keinen Zugriff und er stürzte ab, ich sitze im Nebenraum und höre dann das bootpiepsen.

In der Wohnung ist niemand, ich wohne alleine. Auch hab ich keine USV dran.
Das aktuelle Netzteil hat 3 Netzteile (redundant), wo 3x Kaltstecker reingeht...das habe ich zzt. so angeschlossen und gestern ist der Server trotzdem abgeschmiert. Die Stecker sitzen alle fest drin, da wackelt nichts. Ich kann 2 problemlos abziehen, er läuft weiter, aber das Netzteil fängt an zu piepsen..solange nicht alle 3 stecken. Der Mute-Knopf funktioniert auch. Stecke ich wieder alle rein, hört es auf zu piepsen.

Der Server ist auch abgestürzt, als er direkt in der Wanddose angeschlossen war. Jetzt ist er direkt mit allen 3 Kabeln an unterschiedlichen Wanddosen.
Ich hatte ihn auch an eine Brennenstuhl B5000 angeschlossen, da ist er ebenfalls abgestürzt.

Ansonsten gibt es hier keine (sichtbaren) Stromschwankungen, sämtliche anderen PCs und Geräte laufen und liefen über Jahre problemlos. Seit ich hier wohne (2012) gab es nicht einen Stromausfall.
 
Zuletzt bearbeitet:
Schau dir mal das Board genau an. Insbesondere die Kondensatoren - wenn die ausgewölbt sind, ist das Board hin.

Rob
 
Hat das Ding einen seriellen Port? Häng doch hier einen kleinen RS232 Logger ran und gib auf dem Comport die aktuellen Meldungen aus. (Bsp. Raspi oder ähnliches).

Es könnte auch ein ESD Schaden sein. Auf den Fotos deines Innenlebens ist kein ESD Schutz zu sehen.... :confused:
https://de.wikipedia.org/wiki/Electrostatic_Protected_Area
https://de.wikipedia.org/wiki/Elektrostatische_Entladung

Insbesondere bei Integrierten Schaltkreisen auf Halbleiterbasis ist ESD eine der häufigsten Ausfallursachen. Besonders empfindlich sind Schaltungen aus der Hochfrequenztechnik, Diodenlaser (GaAs-Halbleiter) sowie Feldeffekttransistoren und Leuchtdioden, die oft nur Sperrspannungen von 5 – 30 V vertragen. Da man Entladungen erst ab ca. 2.000 V spüren kann, müssen Maßnahmen getroffen werden, die Aufladungen zuverlässig zu verhindern.
Zum Vergrößern anklicken....
 
KobRheTilla schrieb:
Welche FreeBSD-Version ist das eigentlich?
Zum Vergrößern anklicken....
11.1-RELEASE-p10, frisch kompiliert und installiert (nochmals)

schorsch_76 schrieb:
Häng doch hier einen kleinen RS232 Logger ran und gib auf dem Comport die aktuellen Meldungen aus.
Zum Vergrößern anklicken....
Das ist ne Idee!

schorsch_76 schrieb:
Es könnte auch ein ESD Schaden sein. Auf den Fotos deines Innenlebens ist kein ESD Schutz zu sehen
Zum Vergrößern anklicken....
Bei beiden Boards? Der gleiche Fehler? Da ist auch kein ESD-Schutz drin, ursprünglich hat die Firma coreto die Mühle gebaut. Gesehen habe ich die Schutzpads schon (seeeeehr selten), allerdings eher in Fujitsu/Siemensfertigminikisten.
 
mr44er schrieb:
So hatte ich es, ich hab das erst geändert, als folgendes kam: no suitable dump device was found konnte ich erhaschen beim nächsten boot
Ich bin mir zu 99% sicher, dass ich den swap auch nicht verschlüsselt oder gespiegelt habe.
Zum Vergrößern anklicken....
Dann findet die Magie deine swap aus irgendwelchen Gründen nicht. In dem Fall kannst du sie manuell angeben:
Code: 
dumpdev="/dev/ada2p3"

Da muss natürlich das für dich richtige Device rein. ;)

Nachtrag: Du könntest noch mal kern.panic_reboot_wait_time auf -1 setzen, sodass er im Falle einer Panic nicht automatisch neustartet. Rebootet er trotzdem ungefragt, ist es zumindest keine reguläre Panic.

Code: 
sysctl kern.panic_reboot_wait_time=-1
 
Verdammt...die swapdevs sind doch eli-devices, also USB-Stick opfern. :ugly:
Also...

Code: 
sysctl kern.panic_reboot_wait_time=-1
kern.panic_reboot_wait_time: 15 -> -1
swapon /dev/da8


fstab:
Code: 
# Device                Mountpoint      FStype  Options         Dump    Pass#
/dev/ada0p2.eli         none    swap    sw              0       0
/dev/ada1p2.eli         none    swap    sw              0       0
/dev/ada2p2.eli         none    swap    sw              0       0

/dev/da8                none    swap    sw              0       0

rc.conf
Code: 
dumpdev="/dev/da8"

Bin übers Wochenende nicht daheim...wahrscheinlich gibts keinen Dump, Murphy halt. :rolleyes:
 
Ist zwar unwahrscheinlich, aber wenn du eine bekommen könntest (zur Leihe oder so), würde ich nochmal ne USV dran hängen.
Meine Überlegung: wie es der Teufel will hingen womöglich alle deine Steckdosen an der gleichen Sicherung, an der gleichen Zuleitung, auf der gleichen Phase und so. Dann ist eine andere Steckdose eben kein ausreichender Test, um hier einen Fehler auszuschließen.

ALLE Stecker mal mehrmals raus und wieder einstecken, falls du das noch nicht gemacht hast. Dabei mal ganz genau ansehen (ich nutze eine Lupe oder Brille und gutes Licht). Korrosion oder Versprödung durch Wärme kann zu üblen Fehlern führen.

Abklopfen. Mit einem isolierten Gegenstand (Schraubendreher-Griff), Komponenten und Baugruppen leicht antupfen und sehen, was da womöglich passiert. In allen Richtungen probieren. Auch rhythmisches Klopfen versuchen.

Verbiegen. Insbesondere bei größeren Boards versuchen, die leicht zu verbiegen (was im Betrieb eine Herausforderung ist). Eine Zeit unter Spannung halten und dann eine andere Richtung probieren.

Manchmal kann auch mit Einsatz von Kältespray mechanischer Stress erzeugt werden, der dann einen Fehler zeigt.

Alles andere muss man wohl aufwändig messen.

Ähm: ist da denn überhaupt noch was drin, das nicht getauscht (oder durch Weglassen ausgeschlossen) wurde?
 
pit234a schrieb:
ist da denn überhaupt noch was drin, das nicht getauscht (oder durch Weglassen ausgeschlossen) wurde?
Zum Vergrößern anklicken....

2x Backplane, das chenbro-Platinchen, das alle LEDs und die Knöpfe bedient und das Verbindungskabel, was die Backplanes und das Platinchen verbindet sowie 8x drive caddy.

Die restlichen Tips werde ich noch abarbeiten, wenn ich zurück bin.

Wenn ich ein anderes Mainboard (andere CPU, anderer Hersteller, kein ECC) reinhänge, kann ich die bestehende Installation (generic+altq) gefahrlos booten? Mit Windows knallen so Frankenstein-Versuche nämlich, da schauderts mich schon bei der Erinnerung... :D
 
pit234a schrieb:
würde ich nochmal ne USV dran hängen.
Zum Vergrößern anklicken....
Keine mehr zur Verfügung...

pit234a schrieb:
ALLE Stecker mal mehrmals raus und wieder einstecken, falls du das noch nicht gemacht hast. Dabei mal ganz genau ansehen
Zum Vergrößern anklicken....
Wurde gemacht, nichts zu sehen.

pit234a schrieb:
Abklopfen. Mit einem isolierten Gegenstand (Schraubendreher-Griff), Komponenten und Baugruppen leicht antupfen und sehen, was da womöglich passiert. In allen Richtungen probieren. Auch rhythmisches Klopfen versuchen.
Zum Vergrößern anklicken....
So gut wie überall mal geklöppelt, nix passiert.

pit234a schrieb:
Verbiegen. Insbesondere bei größeren Boards versuchen, die leicht zu verbiegen (was im Betrieb eine Herausforderung ist). Eine Zeit unter Spannung halten und dann eine andere Richtung probieren.
Zum Vergrößern anklicken....
Habe ich gemacht, sogar die Karten und RAMs leicht angestupst/links und rechts gewippelt. Nix.

Die Kiste ist jetzt übers WE ohne Mucken durchgelaufen. Mich beschleicht so langsam das Gefühl, dass es das DVD-Laufwerk war. Das war nämlich immer angeschlossen (hatten wir nicht einen Thread, wo BSD nur mit abgezupftem Laufwerk bootete?)
Ich brauchs eh nicht und wenn das die Lösung ist, bin ich mehr als happy.
 
Heute morgen um kurz nach 3 Uhr ist er wieder automatisch neu gestartet. Habe es nur Piepsen gehört und bin sofort hin und hab den Monitor angeschaltet.
Kein dump auf dem USB-Stick :rolleyes:, weil:
Code: 
Root mount waiting for: usbus2
Root mount waiting for: usbus2
usbd_setup_device_desc: getting device descriptor at addr 4 failed, USB_ERR_TIMEOUT
ugen2.4: <Unknown > at usbus2 (disconnected)
uhub_reattach_port: could not allocate new device

Er ist zwar schon zu anderen Uhrzeiten als 3:00 krepiert, aber als ich gar nicht zuhause war, habe ich die Zeiten nicht mitbekommen.

Bin jetzt darüber gestolpert, was ist davon zu halten?:
https://forums.freebsd.org/threads/kernel-panic-at-3-00-am.29994/
https://forums.freebsd.org/threads/freebsd-10-reboots-crashes-every-day-at-4-00-am.45169/

450.status-security kann ich problemlos laufen lassen....
 
Bei sowas isses immer schwierig, die Ursache eindeutig auf die Hardware oder die Software (unterteilt noch in OS und Userspace) festzunageln.

Falls es wirklich ein Script in den 0300am Skripten wäre, müsstest du das auch manuell forcieren können, durch aufrufen der Komponenten - falls der Server dann wirklich z.B. beim ZFS scrub abraucht: gewonnen! Falls nicht: wieder zurück auf Start - und wieder von vorn losrätseln

Hast scho mal mit nem Bootstick z.B. ein Linux gebootet und das mal länger laufen lassen, ggf sogar mit 'stress-ng' den Rechner ordentlich dabei beschäftigt?
 
turrican schrieb:
Linux gebootet und das mal länger laufen lassen, ggf sogar mit 'stress-ng'
Zum Vergrößern anklicken....
Jein, also Linux nicht....div. stresstools von UBCD und wie sie alle heißen. Alles problemlos.

dmesg:
Code: 
ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20170303/tbfadt-796)
ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe0Block: 64/32 (20170303/tbfadt-748)
Kann das noch auslösend sein? Dagegen könnte ich aber nichts tun...

turrican schrieb:
Falls es wirklich ein Script in den 0300am Skripten wäre, müsstest du das auch manuell forcieren können, durch aufrufen der Komponenten - falls der Server dann wirklich z.B. beim ZFS scrub abraucht: gewonnen!
Zum Vergrößern anklicken....

Dh. ich sollte die alle manuell mal nacheinander anstoßen?
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben