Archive

Posts Tagged ‘Intel’

Problem mit 3ware 9650SE und UEFI BIOS

August 19th, 2013 2 comments

Der etwas betagte 3ware 9650SE-4LPML RAID-Controller wurde auch nach der Übernahme durch LSI weiter gut gepflegt. Die letzte Firmware wurde im Dezember 2012 veröffentlicht. Also bin ich davon ausgegangen, dass der Controller trotz seines Alters noch ganz gut in moderner Hardware funktioniert.

Ich habe versucht, den Controller in einem Asrock H77 PRO4-M Mainboard auf Basis des Intel H77 Chipsatzes und mit einem UEFI BIOS in Betrieb zu nehmen. Erstes Ergebnis: Der Controller wird weder als Boot-Device erkannt noch ist das Controller-BIOS zugänglich. Nicht gut.

Die Hoffnung, diese Kombination noch in einen lauffähigen Zustand zu bringen, war äußerst gering. Trotzdem habe ich das BIOS des Mainboards von Version 1.4 auf 2.0 aktualisiert (was sowieso auf der Liste stand). Und schon beim ersten Boot war das Controller-BIOS zu sehen. Dann noch der Blick in die BIOS-Einstellungen: Auch als Boot-Device kann der 3ware-Controller ausgewählt werden. Schnell ein Betriebssystem installiert und ein paar weitere Tests gemacht: Alles funktioniert! Glück gehabt!

FreeBSD won’t boot on KVM virtualization

July 30th, 2013 Comments off

It’s a somewhat long-standing issue: When using KVM virtualization, your FreeBSD guests are limited to only one CPU. If you choose to add more vCPUs to your FreeBSD guest, it won’t boot at all.

There is an easy workaround to this issue: Change the CPU compatibility mode in KVM/qemu. If you run oVirt this can be done in the cluster settings. I needed to change the CPU name from “Intel Nehalem Family” to “Intel Penryn Family”. Now it’s possible to add more than one vCPU to my FreeBSD guests.

Update: Good news! I’ve just tried the latest oVirt 3,3 (BETA), which utilizes Fedora 19 and qemu-kvm 1.4.2… and surprisingly the problem is gone! Even when using default oVirt/KVM settings, multiple vCPUs will not cause problems anymore.

Windows Update reparieren

January 13th, 2013 Comments off

Unter Windows 7 gibt es mehrere Probleme, die dazu führen, dass Windows Update nicht mehr funktioniert. Deshalb gibt es inzwischen von Microsoft schon länger das Fixit Tool, um die üblichen Reparaturen automatisiert durchzufühen.

Bei einem Acer Notebook hatte ich jetzt ein Windows Update Problem, bei dem alle üblichen Reparaturversuche erfolglos waren. Zur Situation: In dem Notebook wurde die 500 GB Festplatte durch ein 750 GB Modell ersetzt. Zu diesem Zweck wurden die Daten mittels CloneZilla auf das neue Gerät gespiegelt. Das funktionierte vollkommen problemlos.

Danach war Windows Update allerdings kaputt, obwohl sonst alle installierten Programme fehlerfrei arbeiteten. Da Windows Update ohne aussagekräftige Fehlermeldung den Dienst verweigerte und auch in der Ereignisanzeige nichts Brauchbares zu finden war, folgte eine längere Google-Session. Aber die üblichen Lösungsansätze halfen hier nicht weiter.

Dann bin ich zufällig über dieses Post in einem Forum gestolpert. Darin behauptet ein Nutzer namens humprey, dass ein veralteter Intel Rapid Storage Technology Treiber die Ursache für das Problem ist. Eine einfache Aktualisierung dieses Treibers soll das Problem sofort beheben. Das fand ich ein wenig absurd: Was soll der Treiber des SATA-Controllers mit dem Windows Update Dienst zu tun haben?

Doch ziemlich viele User bestätigten, dass ein Update bei Ihnen geholfen hat. Noch dazu wird in dem Post auf einen Supportartikel von HP verwiesen, der genau dieses Problem mit größeren Festplatten beschreibt. HP bietet auch gleich einen neuen Treiber in Version 9.5 zum Download an, in dem es das Problem nicht mehr geben soll. Da ich keine halben Sachen machen wollte, habe ich gleich die neueste Version 11.7 von Intel heruntergeladen und installiert. Das Ergebnis: Unglaublich – Windows Update lief sofort wieder völlig problemlos.

Und was lernen wir daraus? Toyota hatte damals eben doch Recht – “Nichts ist unmöglich!”.

css.php