Am Samstag, 1. Januar 2005 15:07 schrieb Udo Neist:
Am Samstag, 1. Januar 2005 14:39 schrieb Al Bogner: [...]
smartctl -a /dev/hda smartctl version 5.30 Copyright (C) 2002-4 Bruce Allen Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION === Device Model: Maxtor 6B200M0 Firmware Version: BANC1B10 Device is: Not in smartctl database [for details use: -P showall] ATA Version is: 7 ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0 Local Time is: Sat Jan 1 14:26:52 2005 CET SMART support is: Available - device has SMART capability. SMART support is: Enabled
...
SMART Error Log Version: 1 No Errors Logged
SMART Self-test log structure revision number 1 Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error # 1 Extended offline Completed without error 00% 38 ...
S-ATA über die IDE-Treiber. Bei libata funktioniert das nicht.
siehe auch hier: http://smartmontools.sourceforge.net/#testinghelp
Ich benutze aber nur Intelgerätschaften, weil der Ärger, den ich schon mit AMD Boards hatte
Ich hatte auch schon Ärger mit meinen AMD-Rechnern, letztlich kam aber raus, dass die Ursache nicht direkt bei AMD zu suchen war.
Die meisten Probleme haben die Chipsätze verursacht.
Das meine ich, d.h. die Prozessoren an sich sind mittlerweile kompatibel geworden (mein letzter eigener Versuch war wohl dieser erste K6) aber die Chipsätze. Heute treffe ich auf AMD nur in Kundenrechnern und erst seit MS hier eigene Treiber hat, die einigermaßen funktionieren kann man damit einigermaßen arbeiten. Bei den Chipsatz original Treibern steht und fällt die Stabilität des OS mit dem Treiber
Ich hatte vor kurzem einen schönen Artikel darüber gelesen. Bis zum KT133a hatte VIA keinen wirklich vernünftigen Chipsatz produziert. ALi und SiS waren auch nicht wirklich zu gebrauchen. Erst mit dem nForce, der allerdings auch nicht perfekt war, kam Bewegung bei AMD-kompatiblen Chipsätzen. Bei Intel gabs und gibs eigentlich fast nur die hauseigenen Chips, die auch wirklich was taugen. dem kann ich nur zustimmen
Genau das ist ja das Problem. Baut man seinen eigenen Kernel, dann muss man sich um die Sicherheitspatches selber kümmern.
Dafür weiß man aber genau, was man gepatcht hat. Es kam in letzter Zeit öfters vor, dass SuSE fehlerhafte Kernels ausgeliefert hat. Manchmal ist es sogar so, daß ein Patch den anderen behindert, so daß manche Sachen mit Vanilla Kernel tagelang lief und mit dem Suse Kernel alle 20 h abschmierte
Gruß Udo G. Roland