// Buggy Board - Von Problemen mit einem ASRock H61/U3S3

Seit über zwei Monaten schnurrt ein neuer Server in meinem Keller. Die Hardware habe ich bereits vorgestellt. Eigentlich hatte ich auch vor nichts mehr über jene zu schreiben, sondern mehr auf die Software eingehen. Doch dazu soll das Dank einigen Problemen nicht kommen.

Problem: Interrupts via PCI

So viel es mir immer wieder auf, dass die sekundäre Netzwerkkarte (ältere Realtek, nur temprär eingebaut) nach einer gewissen, meistens kurzen Zeit (etwa 30 Minuten) nach dem Reboot der Durchsatz extrem drosselte (um das 20fache langsamer!!) und bei Pings ungewöhnlich hohe Latenzen auftraten.
Dazu hat mir Logcheck dann folgendes gemailt:

Jun 27 02:03:41 host kernel: [ 2671.854895] irq 17: nobody cared (try booting with the "irqpoll" option)
Jun 27 02:03:41 host kernel: [ 2671.854942] Pid: 0, comm: swapper/0 Tainted: G         C   3.2.0-25-generic #40-Ubuntu
Jun 27 02:03:41 host kernel: [ 2671.854945] Call Trace:
Jun 27 02:03:41 host kernel: [ 2671.854947]  <IRQ>  [<ffffffff810db45d>] __report_bad_irq+0x3d/0xe0
Jun 27 02:03:41 host kernel: [ 2671.854960]  [<ffffffff810db6e5>] note_interrupt+0x135/0x190
Jun 27 02:03:41 host kernel: [ 2671.854964]  [<ffffffff810d8f49>] handle_irq_event_percpu+0xa9/0x220
Jun 27 02:03:41 host kernel: [ 2671.854968]  [<ffffffff810d9111>] handle_irq_event+0x51/0x80
Jun 27 02:03:41 host kernel: [ 2671.854972]  [<ffffffff810dc13a>] handle_fasteoi_irq+0x6a/0x110
Jun 27 02:03:41 host kernel: [ 2671.854978]  [<ffffffff81015282>] handle_irq+0x22/0x40
Jun 27 02:03:41 host kernel: [ 2671.854984]  [<ffffffff8166875a>] do_IRQ+0x5a/0xe0
Jun 27 02:03:41 host kernel: [ 2671.854988]  [<ffffffff8165daee>] common_interrupt+0x6e/0x6e
Jun 27 02:03:41 host kernel: [ 2671.854991]  <EOI>  [<ffffffff8108e499>] ? enqueue_hrtimer+0x39/0xc0
Jun 27 02:03:41 host kernel: [ 2671.855000]  [<ffffffff8136b74d>] ? intel_idle+0xed/0x150
Jun 27 02:03:41 host kernel: [ 2671.855003]  [<ffffffff8136b72f>] ? intel_idle+0xcf/0x150
Jun 27 02:03:41 host kernel: [ 2671.855008]  [<ffffffff815051a1>] cpuidle_idle_call+0xc1/0x280
Jun 27 02:03:41 host kernel: [ 2671.855012]  [<ffffffff8101222a>] cpu_idle+0xca/0x120
Jun 27 02:03:41 host kernel: [ 2671.855018]  [<ffffffff8162412e>] rest_init+0x72/0x74
Jun 27 02:03:41 host kernel: [ 2671.855023]  [<ffffffff81cfbc0d>] start_kernel+0x3ba/0x3c7
Jun 27 02:03:41 host kernel: [ 2671.855028]  [<ffffffff81cfb388>] x86_64_start_reservations+0x132/0x136
Jun 27 02:03:41 host kernel: [ 2671.855033]  [<ffffffff81cfb140>] ? early_idt_handlers+0x140/0x140
Jun 27 02:03:41 host kernel: [ 2671.855038]  [<ffffffff81cfb459>] x86_64_start_kernel+0xcd/0xdc
Jun 27 02:03:41 host kernel: [ 2671.855040] handlers:
Jun 27 02:03:41 host kernel: [ 2671.855068] [<ffffffffa00173a0>] rtl8169_interrupt
Jun 27 02:03:41 host kernel: [ 2671.855098] Disabling IRQ #17

Der vergebliche Ansatz: Realtek Treiber?

Zumindest die Meldung rtl8169_interrupt spricht ja in erster Linie für ein Problem mit dem Realtek Treiber. Tatsächlich wird man bei Google mit dieser Fehlermeldung im Gepäck fündig – Linuxuser haben die Suchmaschine mit der Fehlermeldung und der Lösung, die bei mir nichts brachte gefüttert.

Da dieser Weg letzten Endes nicht das gewünschte Ergebnis bracht, hier nur sporadisch mein Vorgehen:

  1. ältere Firmware ausprobiert (Stichwort linux-backports-modules-net-xxx) → kein Erfolg
  2. r8168 statt r8169 ausprobiert → kein Erfolg
  3. andere (rumliegende) Netzwerkkarte, nur dumm, dass die das gleiche Chipset hatte → kein Erfolg
  4. nochmal googlen – die Probleme hängen anscheinend mit Asus und ASRock Boards zusammen

Von Erfolg gekrönter Ansatz

Wenn man sich nun eher irq 17: nobody cared (try booting with the „irqpoll“ option) widmet, wird man schnell fündig. Zu diesem Thema findet sich so einiges in den Archiven der Kernel Mailingliste – Linus meldet sich sogar zu Wort :-)

Für die Sandy Bridge Plattform ist kein nativer PCI Support vorgesehen, in Intels Sandy Bridge Chipsets gibt es also keinen PCI Controller (vereinfacht ausgedrückt). D.h. damit das Mainboard einen PCI Slot anbieten kann, wird eine Brücke von PCIe zu PCI verbaut und genau in dieser Brücke, einem ASMedia Chip liegt das Problem – Er ist anscheinend etwas buggy.
Der Chip ist in vielen ASRock und Asus Sandy Bridge Boards verbaut, unter anderem auch in meinem:

ich@host:~$ lspci | grep "PCIe"
03:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01)

Das Problem tritt logischerweise nicht auf, wenn diese PCI-Slots nicht verwendet werden. Also habe ich die Realtek PCI Netzwerkkarte (ehrlich gesagt: crap, hat Realtek überhaupt „gute“/performante Chipsets im Repertoire?) durch eine Intel PCIe (wesentlich besser) ersetzt und siehe da das Problem ist Geschichte :-)

In den Bugtrackern aller namhaften Distributionen finden sich Einträge über diesen Bug (oder eigentlich Hardwareproblem). Ich habe es mir natürlich einfach gemacht, indem ich die PCI Slots nicht mehr nutze. Nur User, die auf ihr Slots angewiesen sind, dürften ein gewaltiges Problem haben :-(

Problem: Wake on Lan und Reboots ohne Ende

Wenn du dir jetzt dachtest, dass es das mit den Problemen war, hast du dich echt gehörig verschätzt. Natürlich sollte auf einem Server Wake on Lan (WOL) funktionieren, nur hier funktioniert die praktische Funktion trotz Aktivierung im UEFI/BIOS + OS nicht. Im Gegensatz: Das Mainboard besitzt nach Einschalten der Funktion Power up py PCI… noch die unglaubliche Fähigkeit sich nicht mehr ausschalten zu lassen. Statt dessen vollführt das Board nach jedem shutdown -r now (halt funktioniert komplett nicht) einen Neustart.

Wie soll ich nun also WOL testen, wenn ich das System nicht einmal richtig runterfahren kann (WOL funtzt nur, wenn der Rechner richtig ausgeschaltet wurde…). Doch auch hierzu gibt es eine Lösung – dieses mal noch unglaublicher: man aktiviere einfach Wake on mouse/keyboard!

Wie durch Zauberhand funktioniert dann WOL und man kann den Rechner, ohne dass er 5 Sekunden nach dem Shutdown einen Neustart durchzieht, normal ausschalten. Der Lösungsweg ist irgendwie schon verrückt - was hat den bitteschön eine Maus mit WOL zu tun? Wie verrückt die Welt doch ist :-)

Aber trotzdem: Fazit

Ich muss ganz ehrlich sagen, dass diese Probleme wirklich unnötig waren - als nächstes friert die CPU wahrscheinlich ein, weil der Alpenföhn zu schnell dreht :D
Umso schöner ist es dann, wenn man das Problem gefunden und beseitigt hat. Wenn du ein Sandy Bridge Board für ein Linux System brauchst, solltest du vorerst besser nicht zu einem Board mir einer solch problematischen Bridge greifen, wenn du vor hast die PCI Slots zu nutzen. Ansonsten kann ich das Board nicht nur auf Grund des Preis-Leistungsverhältnisses empfehlen.

…und zum Schluss: normale Consumer Hardware ist halt definitiv nichts für Server - aber das 4-5 fache zahlen will man halt auch nicht.

// Neue Hardware – Intel Pentium G630T & Co

Zurzeit arbeite ich an einem neuen System für Hosting/Virtualisierung – die alte Hardware reicht einfach nicht mehr aus. Dazu habe ich mich zu folgender Hardware entschieden:

Insgesamt ein relativ preiswertes und sparsames System, dass aber über genügend Ressourcen für rechenintensive Applikationen verfügt. Wie es damit weiter geht und welche Erfahrungen ich mit dieser Hardware sammeln werde, wirst du bald hier oder auf mein.homelinux.com erfahren. Zusammengebaut sieht das Ganze so aus:

// Weather.chrisge.org – Die Hardware

Nachdem ich das Projekt Weather.chrisge.org bereits in Grundzügen vorgestellt habe, werde ich nun detaillierter auf die verwendete Hardware eingehen. Da der gesamte Entwicklungsprozess mehrere Monate in Anspruch nahm, werde ich nur auf die wichtigsten Dinge eingehen. Falls Fragen auftauchen sollten: melden!

Dieser Beitrag ist Teil der Serie Weather.chrisge.org:

Das Basissystem

Als Basissystem verwende ich eine Seagate Dockstar mit Debian Squeeze. Da das System nur 128 MB RAM und einen ARM Prozessor mit 1,2 GHz verfügt, muss natürlich beachtet werden, dass die verwendete Software möglichst Ressourcen schonend ist. Unter anderem deshalb kann es hilfreich sein, zum Rendern der Daten einen anderen Server zu verwenden und ein sparsames ARM-System nur zum Sammeln und Bereitstellen der Datensätze für den anderen Server zu verwenden. Eine Munin Installation kann hier somit ideal eingesetzt werden.

Eine Übersicht über derzeit verfügbare ARM-Hardware habe ich schon vor längerem auf mein.homelinux.com veröffentlicht:

Speicherplatz

Wenn Motion mit den höchsten Einstellungen bezüglich der Qualität der Bilder bzw. Aufnahmen verwendet wird, können an einem windigen Tag (….und Wolken ohne Ende) täglich schon einmal 1-3 GB an Daten zusammenkommen. Hierfür verwende ich einen 16 GB USB-Stick, der in der Nacht auf einen RAID 1 auf einem anderen Server gesichert werden. Dies ist nicht nur auf Grund des beschränkte Platzbedarfes (damit man auf dem USB nach der Sicherung die Dateien löschen kann) sondern vor allem im Hinblick auf die „Halbbarkeit“ des USB-Sticks - ich habe auf Dockstars bereits 2 Sticks ins Grab geschickt (kaputt geschrieben) - sinnvoll.
Aber, da eine externe Festplatte zu laut wäre und eine SSD zu teuer und sinnlos via USB, werde ich diese Methode wohl oder übel so beibehalten.

Webcam

Zum einen muss die Webcam von Motion unterstützt werden, zum anderen sollte die Bildqualität in einem akzeptablen Rahmen liegen. Es sollte vor allem darauf geachtet werden, dass die Webcam auch mit schlechten Lichtverhältnissen zurechtkommt. Im Endeffekt kann jede Webcam verwendet, die mit video4linux funktioniert, denn dieses setzt Motion ein.

Ich habe mich für eine Logitech HD Webcam C270 (meine hat ein anderes Design als die auf der Logitech Seite) entschieden. Nachträglich würde ich eher eine bessere nehmen, da die C270 gerade bei schlechten Lichtverhältnissen nicht unbedingt eine gute Form macht.

Positionierung

Da ich die Webcam nicht draußen anbringen wollte, musste ich die Webcam innen hinter einer Scheibe platzieren. Das größte Problem hierbei war, dass die Scheibe natürlich spiegelt und das überwiegend dann, wenn Licht von hinten, also von innen auf die Scheibe fällt. So habe ich wie in den Bildern ersichtlich versucht, die Befestigung der Webcam komplett zu verdunkeln. Das ist mir auch relativ gut gelungen. Anschießend muss die Webcam richtig ausgerichtet werden, dazu schließt man jene am besten an einen anderen Rechner an.

Ich kann nur empfehlen, die Webcam so zu platzieren, dass möglichst viel vom Himmel zu sehen ist, also eher eine Ausrichtung in die „Höhe“ als in die „Ferne“. So sind Nachts mehr Sterne erkennbar. Außerdem bietet es sich an, das komplette System draußen zu platzieren.

1-Wire Sensoren und Adapter

Was wäre eine Wetterstation ohne Sensoren? Ich wollte keine fertige Wetterstation wie z.B. die WH1080, da dies mir zu „einfach“ schien - Ich wollte alles selbst basteln und mir die Möglichkeit vorenthalten später eigene Sensoren zu entwerfen (bei 1-Wire relativ einfach) bzw. das sogenannte 1-Wire Netzwerk durch weitere Sensoren jeglicher Art zu erweitern (UV, Solar, Luftdruck, usw.).

1-Wire Sensoren und Equipment gibt es beispielsweise hier:

Ich habe mich relativ schnell für Sensoren von iButtonLink entschieden, da diese (fast! alle) problemlos von der zu verwendenden Software OWFS unterstützt werden. Diese Sensoren gibt es sowohl bei Fuchs Elektronik, als auch bei HomeChip. HomeChip ist zwar billiger, aber durch die Versandkosten gleicht sich das ziemlich schnell mit Fuchs Elektronik aus. Folglich habe ich folgendes Equipment bei Fuchs (Sensoren, Adapter) und Amazon bestellt:

  • 2 x T-Sense (Temperatursensor)
  • 1 x MS-TH (Luftfeuchtigkeit und Temperatur)
  • 1 x LinkUSB (USB-Adapter) → die i-Variante soll auch mit OWFS funktionieren
  • div. Patchkabel (1-Wire wird mit „Lankabeln“ verkabelt)

→ Um zu überprüfen, ob ein Sensor mit OWFS funktioniert, einfach nach [Sensor] OWFS googlen. Die Webseite von OWFS ist leider nicht gerade übersichtlich.

Bald werden noch diese Sensoren folgen:

Verkabeln

Eine grundlegende Einführung in das 1-Wire System findet sich auf HobbyBoards. Wie daraus hervorgeht bestehen folgende Möglichkeiten:

  • Daisy Chain Netzwerk: der Adapter am Rechner wird mit dem Eingang des 1ten Sensors verbunden; dessen Ausgang wird mit dem Eingang des 2ten Sensors verbunden; usw.
  • Star Netzwerk: alle Eingänge der Sensoren werden mit einem Hub verbunden; dieser wird an den Adapter des Rechners verbunden
  • Diese beiden Arten lassen sich natürlich kombinieren!

Als Verbindung dient jew. Patchkabel (in meinem Fall RJ45).

Hobbyboards

Die Sensoren von HobbyBoards besitzen RJ45 Anschlüsse und der zugehörige Adapter verfügt über einen RJ11/12 (Telefonkabel) Anschluss. Somit wird hier ein Adapterstück benötigt. Außerdem benötigen einige Sensoren einen „Power Injector“, da die Stromversorgung über den Bus nicht ausreicht.
Hier muss mit einigem an mehr Kosten gerechnet werden! Zudem ist es ratsam bei dem Betreiber des Shops vorher nachzufragen, ob das Setup so funktioniert.

Hier ist einiges einfach: Der Adapter (LinkUSB[i]) sowie die Sensoren verfügen über den gleichen Anschluss (RJ45), wobei darauf geachtet werden muss, das nicht doch ein anderer Adater mit RJ11/12 wie z.B. der DS9490R bestellt werden. Auch bei iButtonLink gibt es zusätzliche Stromversorgungen (Achtung: ohne Netzgerät!), die nur benötigt werden, falls die Versorgung des Adapters nicht mehr ausreicht.

Mein Setup folgte der Daisy Chain Typologie, somit benötigte ich keinen Hub (den es bei iButtonLink auch gibt) und auf Grund der passenden Anschlüsse auch keine Adapter vor dem eigentlichen Computer Adapter. Eine zusätzliche Versorgung des Buses war ebenfalls nicht von Nöten. So folgten bei mir direkt nach dem Computer Adapter die eigentlichen Sensoren, die einfach nur mit Patchkabel verbunden waren.

Andere

Bei Verwendung anderer 1-Wire Hardware unbedingt auf Anschlüsse und sonstige Voraussetzungen achten!

Radiation Shield / Screen

Wie du bereits in vorherigem Post erfahren hast, waren die ersten Versuche mit den Sensoren nicht sehr überzeugend. Die Temperatur und Luftfeuchtigkeit wich bei Sonneneinstrahlung in extremen Maße ab – kein Wunder: die Sensoren sind schwarz! Folglich musste ein sog. Radiation Shield her. Hier nur ein paar Anleitungen dazu:

Ich habe meinen Screen aus Blumentöpfen hergestellt. Dazu kauft man etwa 12 (weiße! → ich musste meine braunen nachträglich lackieren) Untersetzer mit einem Durchmesser von ungefähr 20-30 cm. Dabei sollten die oberen Beiden einen 2-5 cm größeren Durchmesser besitzen. Nun wird so vorgegangen:

  1. Löcher bohren u. bei allen bis auf dem unteren, sowie den beiden oberen die Mitte herausschneiden (am besten mit einer Blechschere)
  2. Anschließend werden die Untersetzer wie in obig aufgeführten Anleitungen beschrieben, mit Gewindestangen zusammengesetzt. Der Abstand zwischen den einzelnen Untersetzern muss experimentell ermittelt werden, sollte aber bei etwa 1-3 cm liegen. Die einzelnen Untersetzer können entweder durch Verwendung von haufenweise Muttern oder von Abstandhaltern an den Gewindestangen befestigt werden.
  3. Die Sensoren werden an dem 2t obersten Untersetzer befestigt; die Kabel am besten unten (am letzten) herausgeführt.
  4. Alles weitere den erwähnten Anleitungen oder folgenden Bildern entnehmen:

Da ich nur einen T-Sense und den MS-TH in dem Shield platziert hatte, stand mir noch ein T-Sense zur Verfügung. Diesen habe ich in extra Gehäuse gepackt, in das ich Löcher gebohrt und anschließend weiß lackiert habe. Hier das Ergebnis:

→ Der Sensor wird als Outdoor in Sun gemonitored.

// Samsung N210 Plus und Ubuntu – ein Erfahrungsbericht

Seit mittlerweile über 5 Monaten besitze ich ein Samsung N210 Plus – Zeit für einen Erfahrungsbericht. Ich habe damals auf dem Netbook gleich die Natty Beta installiert und damit experimentiert. Unity war und ist aus meiner Sicht immer noch die besten Lösung zum Arbeiten auf solcher Hardware. In diesem Post werde ich auf meine Erfahrungen mit Ubuntu auf einem N210 Plus eingehen.

Zur Hardware

Bevor ich mit den Ubuntu-spezifischen Problemen anfange, hier die grundlegenden Hardwarespezifikationen:

  • Prozessor: Intel ATOM N450 (1,66 GHz; 667 MHz, 512 KB)
  • Arbeitsspeicher: 1 GB (DDR2 / 1 GB x 1)
  • Display: 26 cm (10,1“), WSVGA (1.024 x 600), Matt, LED Backlight Display
  • Grafikprozessor: Intel GMA3150 (Int. Grafik)
  • Festplatte (HDD): 250 GB (5.400 U/min S-ATA)
  • „Akkulaufzeit von bis zu 12 Stunden“
  • Ethernet, Wl-Lan (802.11 b/g/n), Bluetooth (v2.1 mit EDR), Webcam

Mehr Infos...

Die Installation & Einrichtung

Natty installierte ich über einen Livestick, was wirklich schnell ging. Zuvor hatte ich aus Angewohnheit die Windowspartitionen bereits verkleinert und am Ende der Platte eine Partition für die Homes angelegt. Der Großteil der Hardware funktionierte ohne Probleme, nur die Sondertasten (Fn) ließen sich nicht benutzen. Außerdem war die Helligkeit auf die niedrigste Stufe herunter geregelt, was nicht wirklich angenehm für die Augen war.

Die Lösung (I): Linux On My Samsung PPA von Voria

Auf Ubuntuusers fand ich die Lösung auf mein Problem. Einfach das Linux On My Samsung PPA von Voria hinzufügen, das System aktualisieren und die Pakete samsung-tools sowie samsung-backlight installieren:

sudo add-apt-repository ppa:voria/ppa 
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install samsung-tools samsung-backlight

Nach einem Reboot funktionierten sämtliche Fn Tasten und die Helligkeit lies sich regeln. Mit der GUI Samsung Tools Einstellungen konnte ich nun die Einstellungen für die Tasten ändern, sowie zahlreiche Energiesparoptionen aktivieren. Ein bisschen irritierend war, dass die Webcam über die Fn Taste für „€“ ausgeschaltet werden konnte. Doch leider existiert keine weitere Taste, die frei wäre und auf die ich diese Funktion legen könnte.

Doch zu früh gefreut: Wenn die Displayhelligkeit zu schnell hoch oder herunter geregelt wurde, begann der Bildschirm ununterbrochen die Helligkeit zu verändern. Dies trat beispielsweise auf, wenn ich das Netzteil zog und das Gerät in den Akkubetrieb wechselte. Das Ergebnis war ein blickendes Netbook, dass in diesem Fall nicht mehr richtig zu bedienen war.

Die Lösung (II): Grub & Parameter des Kernelmoduls

Wenn du dieses Posting als Anleitung für dein Samsung Netbook verwendest, kann es sein, dass diese Änderungen, die in diesem Abschnitt (Grub, Kernelmodul) bereits durch die Pakete aus dem oben erwähnten PPA durchgeführt wurden.

Auf diese Lösung wurde ich hier fündig. In der /etc/default/grub:

sudo nano /etc/default/grub

habe ich die Zeile

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

in

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash acpi_backlight=vendor"

geändert. Anschließend habe ich Grub geupdated:

sudo update-grub2


Nun habe ich der /etc/modprobe.d/samsung-backlight.conf:

sudo nano /etc/modprobe.d/samsung-backlight.conf

diese Zeile hinzugefügt:

options samsung_backlight use_sabi=0 force=1

und das System neu gestartet. Später wurde diese Zeile durch ein Upgrade des Kernels auf

options samsung-backlight use_sabi=0 levels=8 force=1

geändert.

Erfahrungen & Fazit

Von einem Netbook darf man natürlich nicht viel Leistung erwarten. Als ich damals die Natty Beta installiert habe, war ich positiv von der Reaktion/Geschwindigkeit des Geräts überrascht und das bin ich immer noch. Zum Surfen, Lesen von E-Books, E-Mails abrufen und für kleinere Serverarbeiten ist ein Netbook natürlich gemacht.

Akkulaufzeit

Die angegebenen 12 Stunden Betriebszeit im Akkubetrieb habe ich noch nie erreicht und werde ich wahrscheinlich auch nie. Spätestens nach etwa 6 Stunden war Schluss. Das liegt wahrscheinlich auch daran, dass ich wenig an den Energiesparoptionen herum gefummelt habe und die Bildschirmhelligkeit meistens nach der automatischen Herunter-regelung wieder etwas hochstelle, weil das Display so einfach angenehmer ist.
Mit ein wenig Optimierung, die dank den Samsung Tools wirklich einfach ist, dürften 10 Stunden eventuell machbar sein.

Hardwareunterstützung

Wie bereits erwähnt gibt es mit der Hardwareunterstützung keine Probleme. Im Gegensatz: durch die Samsung Tools kann ich sogar die CPU-Temperatur bestimmen und den Lüftermodus runter regeln sowie Webcam, Bluetooth und WLAN über die Fn Tasten einzeln ab- und anschalten, was wirklich genial ist. Bei dem Lüftermodus „Leise“ sind fast keine Betriebsgeräusche zu vernehmen.

Das Touchpad funktioniert ohne Probleme. Meine derzeitigen Einstellungen sind so ausgelegt, dass ich die Tasten für Rechts- und Linksklick nicht mehr benötige. Am Rand, sowie unten kann ich scrollen, ein „Touch“ mit einem Finger ist logischerweise ein Rechtsklick, einer mit zwei Fingern ein Rechtsklick. Auch der Standby funktioniert erstaunlich zuverlässig, was nicht gerade eine Stärke von Natty ist.

Das Einzige was mich stört ist die Webcam. So kann ich mit jener keine Videos, sondern nur Bilder aufnehmen. Waran das liegt, habe ich bis heute nicht herausgefunden.

Fazit

Ich kann das Samsung N210 (Plus) jedem Ubuntuuser empfehlen. Für meine Einsatzgebiete ist das Gerät wirklich ideal. Aber ohne Samsung Tools bleibt das Netbook fast unbedienbar. Hier gilt mein Dank den Machern des Linux On My Samsung PPAs!

Natty und Unity leisten auf einem solch kleinen Display wirklich hervorragende Arbeit. Ich könnte mir kein Gnome 2 und schon gar kein Windows 7 darauf vorstellen.

Hello World!

This is the personal website of Christoph Winkler aka chrisge.
Here you will find a sort of blog and some information about me and my projectshave fun!

Recent Comments
Latest Tweets
QR-Code: aktuelle Seiten-URL
Falls nicht anders bezeichnet, ist der Inhalt dieses Wikis unter der folgenden Lizenz veröffentlicht: CC Attribution-Noncommercial-Share Alike 3.0 Unported