Dell Precision T3600
Einrichtung einer Dell Precision T3600 Workstation unter Linux
Bei ITSCO habe ich mir eine gebrauchte Dell Workstation "Precision T3600" gekauft. Das ist ein sehr gutes, zum Neupreis für mich absolut unbezahlbares Arbeitspferd mit E5-1650 CPU ("Sandy Bridge"), Intel C602 Chipsatz und einer NVidia Quadro 5000 Grafikkarte. Ich möchte hier ein paar Zeilen zur Linux Installation auf diesem Gerät schreiben, da ich ein paar kleine Probleme hatte, die aber alle lösbar sind. Zusammengefasst in einem Satz kann man schreiben das Linux (hier Kubuntu 16.04) sehr gut auf dieser Workstation/PC funktioniert.. Was heißt das konkret: Die eingebaute Hardware ist unterstützt: Grafik, Netzwerk und alle internen Schnittstellen. Es muß nicht gebastelt werden, sondern alles funktioniert out-of-the-box (Stimmt nicht ganz, mehr dazu unten)
Im Dell Precision T3600 eingebaute Hardware
In meiner konkreten Maschine war vorhanden
- Xeon E5-1650
- Nvidia Quadro 5000
- 16 GB ECC REG RAM (4*4GB DDR3-1600 Module)
- Seagate Barracuda 7200 (1,5 TB, ST31500341AS)
Den sonst wohl immer verbauten Dell PERC H310 SAS Controller hat entweder der Vorbesitzer oder ITSCO ausgebaut. Das Mainboard hat aber sowieso einen SAS und SATA Controller on-board
Einschub zu Umbauten bis Mai 2023
Mittlerweile ist die Maschine mehrfach von mir umgebaut worden, sie hat jetzt 64 GB ECC REG RAM (4*16GB DDR3-1600 Module), dazu eine NVidia Geforce GTX 1060 Grafikkarte. Um schnellen Plattenplatz zu haben habe ich so eine PCIe zu M.2 Karte und ein nvme Modul von Samsung eingebaut.
Nachdem nun einige Jahre ins Land gegangen sind, ist die Maschine immer noch gut nutzbar, allerdings gibt es eine Sache die nun doch etwas lästig ist: Das BIOS ist sehr zickig mit den Bootlaufwerken - ich habe es neulich (Mai 2023) nicht geschafft einen USB Stick mit ubuntu 22.04 zu starten. Da bin ich wohl von dem in diesem Forenartikel beschriebenen Problem betroffen. Der Versuch "UEFI" Boot zu nutzen kann man sich auch gerade schenken, da dann gerne mal alle Bootmenüeinträge verschwinden, am zuverlässigsten startet die Maschine von einer "klassischen" SSD oder Festplatte vom MBR ("Legacy Boot").
Das "schwierigste hat sich für mich dann als das leichteste herausgestellt: Da ich weder eine brennbare DVD habe, noch irgendwie ein Startfähiges Image auf USB hinbekommen habe, habe ich via PXE Boot gestartet. Das lief dann ganz gut. Das via PXE gebootete System eigenete sich dann auch als "Rettungsssystem" um das NVMe zu löschen (obwohl da nur /home drauf ist, weigert sich mke2fs von ubuntu 22.04 das im laufenden System zu formatieren, obwohl /home ganz normal abgehängt werden konnte (root - login via konsole) ).
Vorhandene PCI Devices (Stark gekürzt, nur die "interessanten"):
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 05) 00:1a.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #2 (rev 05) 00:1b.0 Audio device: Intel Corporation C600/X79 series chipset High Definition Audio Controller (rev 05) 00:1d.0 USB controller: Intel Corporation C600/X79 series chipset USB2 Enhanced Host Controller #1 (rev 05) 00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 05) 00:1f.3 SMBus: Intel Corporation C600/X79 series chipset SMBus Host Controller (rev 05) 03:00.0 VGA compatible controller: NVIDIA Corporation GF100GL [Quadro 5000] (rev a3) 03:00.1 Audio device: NVIDIA Corporation GF100 High Definition Audio Controller (rev a1) 05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 05) 07:00.0 USB controller: NEC Corporation uPD720200 USB 3.0 Host Controller (rev 04)
Jede Menge weiterer PCI Geräte sind noch darüber hinaus zu sehen, davon sind die meisten "System peripheral" Komponenten und Bestandteil der CPU oder des C602 Chipsatzes.
Umbaumaßnahmen für den Heimbetrieb
HDD-Probleme
Danach habe ich das mitgelieferte Windows 7 sich fertig installieren lassen. Das eigentlich nur um zu schauen ob die Maschine den Transport überstanden hat und prinzipiell funktioniert. Nachdem das sichergestellt war habe ich die Bootreihenfolge angepasst und einen USB Stick mit Kubuntu 16.04 gestartet. Hier war schon offensichtlich zu sehen, daß die ganze eingebaute Hardware funktioniert, daher habe ich den Rechner nochmal umgebaut.
Auf der Hauptplatine des Precision T3600 sind 6 "SATA" Buchsen vorhanden. In der Reihenfolge von den Steckkartenplätzen weg eine blaue, 3 schwarze, eine weiße und noch eine schwarze Buchse. Hierbei sind die blaue und die 3 darauf folgenden schwarzen Buchsen je SAS Anschlüsse die vom on-Board SAS Controller bedient werden (PCI-Komponente "05:00.0 Serial Attached SCSI controller: Intel Corporation C602 chipset 4-Port SATA Storage Control Unit (rev 05)"). Dieser Controller wird von Linux vom "isci" Treiber unterstützt. Die weiße und die darauf folgende schwarze Buchse ist mit der PCI Komponente "00:1f.2 SATA controller: Intel Corporation C600/X79 series chipset 6-Port SATA AHCI Controller (rev 05)" verbunden. In der online verfügbaren Boardbeschreibung wird darauf leider nicht näher eingegangen, es wird nur erwähnt daß die blaue Buchse speziell für Platten geeignet ist.
Der Beschreibung folgend habe ich eine schon vorhandene Samsung SSD 840 (Evo) Series an die blaue Buchse und die 1,5 TB Seagate Platte an die darauf folgende Buchse angeschlossen. Die 1,5 TB Seagate Platte habe ich umgesteckt, die war nämlich an der weißen Buche angeschlossen
CRC-Busfehler
Beim Bootup meldet der Linux-Kernel 4.4.0 folgendes über die SSD am SAS Controller
Apr 24 11:42:22 python kernel: [ 2.724900] ata7.00: ATA-9: Samsung SSD 840 Series, DXT06B0Q, max UDMA/133 Apr 24 11:42:22 python kernel: [ 2.724916] ata7.00: 488397168 sectors, multi 16: LBA48 NCQ (depth 31/32) Apr 24 11:42:22 python kernel: [ 2.725426] ata7.00: configured for UDMA/133 Apr 24 11:42:22 python kernel: [ 2.725524] sas: --- Exit sas_scsi_recover_host: busy: 0 failed: 0 tries: 1 Apr 24 11:42:22 python kernel: [ 2.740733] scsi 6:0:0:0: Direct-Access ATA Samsung SSD 840 6B0Q PQ: 0 ANSI: 5 Apr 24 11:42:22 python kernel: [ 2.740932] sas: Enter sas_scsi_recover_host busy: 0 failed: 0
Nach der Installation kam es gelegentlich zu folgendem Fehlerbild im Kernel-Log
Apr 24 14:09:22 python kernel: [ 354.760996] ata7.00: exception Emask 0x0 SAct 0x7fc00000 SErr 0x0 action 0x6 frozen Apr 24 14:09:22 python kernel: [ 354.761003] ata7.00: failed command: READ FPDMA QUEUED Apr 24 14:09:22 python kernel: [ 354.761011] ata7.00: cmd 60/80:00:80:fb:c6/00:00:08:00:00/40 tag 22 ncq 65536 in Apr 24 14:09:22 python kernel: [ 354.761011] res 40/00:00:00:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 24 14:09:22 python kernel: [ 354.761015] ata7.00: status: { DRDY } Apr 24 14:09:22 python kernel: [ 354.761019] ata7.00: failed command: WRITE FPDMA QUEUED
Der Rechner hat sich dann gelegentlich ganz weghängt (keine Platten mehr verfügbar).
verschiedene Doku im Internet besagt, daß die SSD Platte "lügt" und gar kein NCQ (native command queing) unterstützt. Ich habe in
/etc/rc.local
die Anweisung echo "1" >
/sys/block/sda/device/queue_depth
aufgenommen um kein Command Queueing
auf der SSD mehr zu machen. Das Problem wurde dadurch zwar besser, aber nicht
gelöst. Es kam dann z.B. zu folgendem Fehler.
Apr 25 21:36:45 python kernel: [ 19.995680] isci 0000:05:00.0: isci_task_abort_task: abort task not needed for ffff88041a0d3000 Apr 25 21:36:45 python kernel: [ 19.995683] isci 0000:05:00.0: isci_task_abort_task: Done; dev = (null), task = ffff88041a0d3000 , old_request == (null) Apr 25 21:36:45 python kernel: [ 19.995684] sas: sas_scsi_find_task: task 0xffff88041a0d3000 is done Apr 25 21:36:45 python kernel: [ 19.995685] sas: sas_eh_handle_sas_errors: task 0xffff88041a0d3000 is done Apr 25 21:36:45 python kernel: [ 19.995688] sas: ata7: end_device-6:0: cmd error handler Apr 25 21:36:45 python kernel: [ 19.995699] sas: ata7: end_device-6:0: dev error handler Apr 25 21:36:45 python kernel: [ 19.995703] sas: ata8: end_device-6:1: dev error handler Apr 25 21:36:45 python kernel: [ 19.995706] ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen Apr 25 21:36:45 python kernel: [ 19.995708] ata7.00: failed command: READ DMA Apr 25 21:36:45 python kernel: [ 19.995711] ata7.00: cmd c8/00:70:78:a0:c9/00:00:00:00:00/e6 tag 17 dma 57344 in Apr 25 21:36:45 python kernel: [ 19.995711] res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout) Apr 25 21:36:45 python kernel: [ 19.995713] ata7.00: status: { DRDY } Apr 25 21:36:45 python kernel: [ 19.995715] ata7: hard resetting link
Ursache sind offensichtlich CRC Fehler bei der SATA Datenübertragung. Im SMART der SSD konnte ich mit smartctl
folgendes auslesen:
SMART Attributes Data Structure revision number: 1 Vendor Specific SMART Attributes with Thresholds: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0 9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 1201 12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 908 [...] 199 CRC_Error_Count 0x003e 099 099 000 Old_age Always - 17 [...]
Jedes Mal wenn eine der obigen Meldungen im Log erschien, wurde der "199" "CRC_Error_Count" um eins erhöht. Viele Doku im Internet empfiehlt das Kabel zu tauschen, welches aber zuvor prima funktioniert hat. Ich habe die SSD einfach an den weißen onboard SATA Port (Das CD-ROM hängt dann an dem anderen) angeschlossen und seitdem funktioniert sie einwandfrei. Ich vermute daß die unterschiedlichen Signalpegel von SAS und SATA hier evtl. am Controller Schwierigkeiten machen. Der Linux-Treiber "isci" kennt auch Optionen um manuell die Kabellänge ("kurz, mittel, lang") zu setzen, das habe ich aber dann gar nicht mehr probiert. Die 1,5 TB SATA Festplatte macht am SAS Port keine Schwierigkeiten.