Hetzner Server instabil

unull

Nervensäge
Hallo Leute,

ich habe seit kurzem einen FreeBSD-Server bei Hetzner gemietet, auf dem momentan 9.1RC1 laeuft.

Seit ca. zwei Wochen tritt immer folgendes Szenario auf:

Wenn grosse Dateien per HTTP angefordert werden ist der Rechner kurz nicht zu erreichen, dann finde ich im Log folgendes:

Sep 16 14:47:46 achilles kernel: ahcich4: Timeout on slot 13 port 0
Sep 16 14:47:46 achilles kernel: ahcich4: is 00000000 cs 00002000 ss 00000000 rs 00002000 tfd c0 ser00000 cmd 0000cd17
Sep 16 14:47:46 achilles kernel: (ada0:ahcich4:0:0:0): WRITE_DMA48. ACB: 35 00 7d 40 10 40 53 00 00 01
Sep 16 14:47:46 achilles kernel: (ada0:ahcich4:0:0:0): CAM status: Command timeout
Sep 16 14:47:46 achilles kernel: (ada0:ahcich4:0:0:0): Retrying command

Mein ZFS-Pool wird dann auch immer gleich als "degraded" angezeigt, weil angeblich eine Platte fehlt. Neustarten ins Rescue-System hat zur Folge, dass beiden Platten nicht mehr auffindbar sind. Ich kann den Rechner in dem Zustand auch nicht per Strg+Alt+Entf via Robot neustarten. Lediglich ins Rescue-System komme ich.

Ich habe diesbezueglich auch schon mehrere Tickets an Hetzner geschrieben und dort um einen Hardware-Check gebeten. Bisher war jedesmal laut Hetzner nichts zu finden und nach dem Check hat der Rechner wird korrekt gebootet und lief eine Weile, bis diese seltsamen Lesefehler auftreten.

Ich denke, dass diese Fehler auch erst seit dem Update auf 9.1RC1 aufgetreten sind und die Kister vorher ca. zwei Monate problemlos durchlief.

Koennte das etwas anderes als ein Hardware-Problem sein? So langsam sind meine Moeglichkeiten bei Hetzner erschoepft, da saemtliche Hardware-Checks positiv verlaufen sind.

Bin fuer jeden Tipp dankbar.
 
Setze mal 'hint.ahci.4.msi="1"' per /boot/loader.conf. MSI abzuschalten können Wunder wirken.
 
Das Rescuesystem hat soweit mir bekannt keinen ZFSv28 Support. Demnach kannst du den ZPool nicht in das Rescuesystem importiern.
 
Hat leider nichts geholfen. Gestern abend alles wunderbar, heute abend ist der Rechner wieder im Zombie-Modus gelandet. Resetten hilft auch nichts mehr. Ich bin ratlos.
 
Hi,
Timeouts in diesem Zusammenhang mit FreeBSD 9.x habe ich auch schon öfter gesehen. In den meisten Fällen war hierbei eine SSD oder HD mit defekter Firmware die Ursache für die Timeouts. Danach kam regelmäßig der Kernelpanicbär zu Besuch. Ein Update der SSD / HD Firmware hat das Problem meistens gelöst.

Bei einer SSD im Test hier gibt es da noch nichts Neueres und das Problem tritt nach wie vor sporadisch auf.

Hier ein paar Eckdaten:

Code:
# cat /var/run/dmesg.boot|grep ahci
ahci0: <Intel ICH9 AHCI SATA controller> port 0xa400-0xa407,0xac00-0xac03,0xa880-0xa887,0xa800-0xa803,0xa480-0xa49f mem 0xfe777000-0xfe7777ff irq 19 at device 31.2 on pci0
ahci0: AHCI v1.20 with 6 3Gbps ports, Port Multiplier not supported
ahcich0: <AHCI channel> at channel 0 on ahci0
ahcich1: <AHCI channel> at channel 1 on ahci0
ahcich2: <AHCI channel> at channel 2 on ahci0
ahcich3: <AHCI channel> at channel 3 on ahci0
ahcich4: <AHCI channel> at channel 4 on ahci0
ahcich5: <AHCI channel> at channel 5 on ahci0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0

# cat /var/run/dmesg.boot | grep ada0
ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
ada0: uhub5: 2 ports with 2 removable, self powered
ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)
ada0: Command Queueing enabled
ada0: 57241MB (117231408 512 byte sectors: 16H 63S/T 16383C)
ada0: Previously was known as ad4

# camcontrol identify ada0
pass0: <MKNSSDCR60GB-DX 320ABBF0> ATA-8 SATA 3.x device
pass0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes)

protocol              ATA/ATAPI-8 SATA 3.x
device model          MKNSSDCR60GB-DX
firmware revision     320ABBF0
serial number         MKN1139A00000247xx
WWN                   0000120000000000
cylinders             16383
heads                 16
sectors/track         63
sector size           logical 512, physical 512, offset 0
LBA supported         117231408 sectors
LBA48 supported       117231408 sectors
PIO supported         PIO4
DMA supported         WDMA2 UDMA6 
media RPM             non-rotating

Feature                      Support  Enabled   Value           Vendor
read ahead                     yes      yes
write cache                    yes      yes
flush cache                    yes      yes
overlap                        no
Tagged Command Queuing (TCQ)   no       no
Native Command Queuing (NCQ)   yes              32 tags
SMART                          yes      yes
microcode download             yes      yes
security                       yes      no
power management               yes      yes
advanced power management      yes      no      254/0xFE
automatic acoustic management  no       no
media status notification      no       no
power-up in Standby            yes      no
write-read-verify              yes      no      0/0x0
unload                         yes      yes
free-fall                      no       no
data set management (TRIM)     yes

Schau also am Besten erstmal ob die Firmware der HD bzw. SSD aktuell ist und ob die Einstellungen der Platte bzw. SSD für das was Du damit treibst ok sind (z.B. Power Management und solche Scherze).

Beste Grüße
Bummibär
 
Zuletzt bearbeitet:
...
Neustarten ins Rescue-System hat zur Folge, dass beiden Platten nicht mehr auffindbar sind.

Das Rescuesystem findet die nicht mehr?
Was passiert mit anderen Rescuesystemen? Linux?

Ich kann den Rechner in dem Zustand auch nicht per Strg+Alt+Entf via Robot neustarten.
Lediglich ins Rescue-System komme ich.

Wie startest Du ihn denn dann neu?
Per Hardware-Reset oder muß einer gegen die Kiste treten gehen?
 
Bummibär bringt micht auf eine Idee. Lange Zeit verbaute Hetzner ja den guten Intel X57-Chipsatz in Kombination mit noch besseren Samsung-Platten. Die Kombination war sowas von inkompatibel, dass explodierte unter FreeBSD schon beim schief anschauen. Der einzige Ausweg war, dass seit 9.0 nun als Standard gesetzte ATACAM abzuschalten und auf ATA zu setzen. Alternativ konnte man seinen Kernel patchen, damit NCQ nicht genutzt wird. Lange Rede, kurzer Sinn: Schaue mal, ob du eine solche Kombination hast. Dann sehen wir weiter. Dazu gibt es auch einen PR (der nicht gefixt werden wird, da es ein Hardwareprob ist) - http://www.freebsd.org/cgi/query-pr.cgi?pr=157397

Edit: Eine aktuelle Version des Patches gibt es hier - http://lists.freebsd.org/pipermail/freebsd-stable/2012-February/066170.html
 
Hi,

das Rescue System kannst du in die Tonne dort treten, da es 1. leider nicht aktuell genug ist und 2. wichtige Bestandteile für solche sinnvollen Aktionen (z.B. div. Kernel Module) schlicht vollständig fehlen. Wissen tut das der Anbieter schon seit mindestens einem 3/4 Jahr - reagieren leider nicht wirklich. Schlag dem Support einfach per Mail vor eine seiner zig hunderte von Kunden teuer bezahlten FreeBSD 9 amd64 DVD einzulegen und boote einfach davon. Dann stehen dir aktuelle ZFS und sonstige Tools und Kernel Module zur Verfügung.

Beste Grüße
Bummibär
 
Bummibär bringt micht auf eine Idee. Lange Zeit verbaute Hetzner ja den guten Intel X57-Chipsatz in Kombination mit noch besseren Samsung-Platten. Die Kombination war sowas von inkompatibel, dass explodierte unter FreeBSD schon beim schief anschauen. Der einzige Ausweg war, dass seit 9.0 nun als Standard gesetzte ATACAM abzuschalten und auf ATA zu setzen. Alternativ konnte man seinen Kernel patchen, damit NCQ nicht genutzt wird. Lange Rede, kurzer Sinn: Schaue mal, ob du eine solche Kombination hast. Dann sehen wir weiter. Dazu gibt es auch einen PR (der nicht gefixt werden wird, da es ein Hardwareprob ist) -

Soweit ich das im Linux-Rescue-System nachvollziehen kann, hat die Kiste ein MSI X58 Pro-E Mainboard mit diesem Chipsatz: "Intel® X58+ICH10R".

Scheint also damit auch aufzutreten oder das Problem ist ein anderes.

Die Symptome sind bei mir aber indentisch. I/O-Last und der Rechner geht in den Zombie-Modus. Neustarten ins Rescue-System geht per Hardware-Reset, aber FreeBSD bootet erst nach einem Hardware-Check (ich vermute, dass dabei der Rechner wohl mal ausgeschalten wird, wie in dem Post auf der Mailingliste beschrieben).
 
Der einzige Ausweg war, dass seit 9.0 nun als Standard gesetzte ATACAM abzuschalten und auf ATA zu setzen.

Aus aktuellem Anlass (heute ist wieder mal eine Platte verschwunden im laufenden Betrieb): Wie schalte ich ATACAM ab? Muss ich dafuer den Kernel neubauen?

Aendern sich da meine Device-Namen oder muss ich sonst nochwas beachten?
 
Hi,
Timeouts in diesem Zusammenhang mit FreeBSD 9.x habe ich auch schon öfter gesehen. In den meisten Fällen war hierbei eine SSD oder HD mit defekter Firmware die Ursache für die Timeouts. Danach kam regelmäßig der Kernelpanicbär zu Besuch. Ein Update der SSD / HD Firmware hat das Problem meistens gelöst.

Das Problem ist, dass ich selber wohl nicht ohne weiteres Firmware-Updates bei der Kiste durchfüren kann.
 
Hi,
dafür nutzt Du am oifachsten den virtual Media Support mittels IPMI um ein Live System per ISO Image remote über das Netz zu booten. Dann mit IPMI auf die Kiste mit dem laufenden LIVE OS zugreifen. Danach mountest Du tmpfs für /tmp. Nun oifach mit dem Live OS und fetch oder scp oder sonstwas über das Netz bärig fein das Archiv mit dem Firmware File und FW Flasher laden, entpacken nach /tmp (das wo du mit tmpfs ins ram gemounted hast) und führst von dort aus das Firmware Update aus. Da kein System von der SSD / HD gestartet ist und nichts gemounted außer das Live OS von IPMI aus per virtual Media und die tmpfs auf /tmp sollte das problemlos gehen. Danach die Maschine mit shutdown -r now oifach oi mal neu booten. Dat wars :) - bärig oifach.

Beste Grüße
Bummibär
 
Hetzner benutzt Desktophardware ohne IPMI. Es ist halt ein Billighoster bei dem man schnelle Rechner billig bekommt. Nirgendwo stand etwas von zuverlässig.
 
unull schrieb:
Wie schalte ich ATACAM ab? Muss ich dafuer den Kernel neubauen?
Vorweg sei gesagt, dass Kernel ohne ATACAM ab 9.0 nicht mehr unterstützt sind. Es kann also noch funktionieren, muss aber nicht. Du musst einen neuen Kernel ohne "options ATA_CAM" bauen. Wie du schon sagst, ändern sich die Device-Namen, aus "adaX" wird "adY".
 
Ich habe letzte Woche fuer beide Platten via camcontrol die "tags" auf 1 gesetzt und seitdem keine Probleme mehr gehabt.

Code:
/sbin/camcontrol tags ada0 -N 1
/sbin/camcontrol tags ada1 -N 1
 
Hi,
hatte ähnliche Probleme bei einem EX 4S System mit FreeBSD 9.0. Hatte damals auch mal den Support beauftragt zu schauen, aber Platten waren ok. System lief 1 bis 2 Tage und dann war eine Platte weg ;(

Im Log kam folgende Meldung:

Apr 23 15:51:49 meinsrv kernel: ahcich1: AHCI reset: device not ready after 31000ms (tfd = 00000080)
Apr 23 15:56:31 meinsrv kernel: ahcich1: AHCI reset: device not ready after 31000ms (tfd = 00000080)
Apr 23 15:56:31 meinsrv last message repeated 8 times
Apr 23 15:56:31 meinsrv kernel: (ada1:ahcich1:0:0:0): lost device
Apr 23 15:57:19 meinsrv kernel: ahcich1: AHCI reset: device not ready after 31000ms (tfd = 00000080)
Apr 23 15:57:19 meinsrv kernel: ahcich1: Poll timeout on slot 6 port 0
Apr 23 15:57:19 meinsrv kernel: ahcich1: is 04400040 cs 00000040 ss 00000000 rs 00000040 tfd 80 serr 048d0802 cmd 00004617
Apr 23 15:57:20 meinsrv kernel: GEOM_MIRROR: Device swap: provider gpt/swap1 disconnected.
Apr 23 15:57:20 meinsrv kernel: (ada1:ahcich1:0:0:0): removing device entry
Apr 23 15:58:08 meinsrv kernel: ahcich1: AHCI reset: device not ready after 31000ms (tfd = 00000080)
Apr 23 15:58:08 meinsrv kernel: ahcich1: Poll timeout on slot 6 port 0
Apr 23 15:58:08 meinsrv kernel: ahcich1: is 04400040 cs 00000040 ss 00000000 rs 00000040 tfd 80 serr 048d0802 cmd 00004617



Hab dann in die /boot/loader.conf folgendes eingetragen, was zum Erfolg führte.

kern.cam.ada.default_timeout="60" # default: 30

Seit dem keine Probleme damit ;)

Grüße
 
Zurück
Oben