Re: Fragen zu Ungereimtheiten mit FreeBSD 7.0 und anhängiger Software

From: Oliver Fromme <olli(at)lurza.secnetix.de>
Date: Tue, 15 Jul 2008 10:26:09 +0200 (CEST)

Polytropon <freebsd(at)edvax.de> wrote:
> [...]
> Mein Rechner ist zugegebenermaßen nicht mehr der neuste, aber
> unter 5.x war das Teil eine Rakete. Das mag man sich ange-
> sichts der folgenden Beschreibung kaum vorstellen, aber es
> war wirklich so:
>
> Board mit Intel-Chipsatz
> Intel Pentium 4, 2000 MHz
> 768 MB SDR-SDRAM
> ATI Radeon 9000/9000 Pro RV250
> 3C905-TX Fast Etherlink 10/100 PCI TX NIC
> C-Media CMI8738/PCI C3DX

Nur zum Vergleich: Ich habe just am Wochenende ein altes
Notebook (Bj. 2001) aus dem Schrank gekramt. Da war noch
ein altes 4-stable von 2002 drauf, das ich dann auf ein
aktuelles 7-stable (von gestern) aktualisiert habe.

Daten: Pentium-III 850 MHz (i440BX Chipsatz), 256 MB RAM,
S3 Savage MX Graphik, Realtek re(4) NIC, ESS Audio.

Insgesamt war das Update problemlos. Ich habe keine Bench-
mark oder sonstige "harte" Vergleichsverfahren gemacht,
aber rein vom Gefühl her würde ich sagen, dass das Büchlein
jetzt besser läuft als vorher.

> Da die Kiste tadellos funktioniert, gedenke ich auch nicht, mir
> was neues zu kaufen, weder mein Gehalt noch meine moralischen
> Vostellungen würden einen solchen Schritt rechtfertigen. :-)

Verständlich. Den technischen Daten nach sollte die Kiste
für normale Anwendungen vollkommen ausreichen. Mein eige-
ner Hauptarbeitsplatz daheim unterscheidet sich nur gering-
fügig von Deinen Angaben, dürfte sogar etwas langsamer sein
(Pentium-M 1600 MHz, 1 GB RAM, i915 Graphik, Realtek rl(4)
NIC, ICH6 Audio).

> Bisher hatte ich FreeBSD 5.x, und nur durch einen Datenkollaps
> (zu dessen Behebung ich ggf. nochmal gesondert vortragen darf)
> war ich gezwungen, diese Umgebung zu verlassen und mich dem
> neuen FreeBSD 7.0 zu widmen (wenngleich ich schon Testsysteme
> mit 6.x und 7.x hatte, aber nie zu ernsthaftem Gebrauch).

Um ehrlich zu sein, ich habe 5.x niemals irgendwo produktiv
eingesetzt. Es war der schlechteste Branch, den ich bei
FreeBSD erlebt habe. Auf den meisten Rechnern bin ich von
4.x direkt auf 6.x gegangen. Die Erfahrungen anderer haben
das häufig bestätigt, sogar viele langjährige FreeBSD-
Developer geben das zu.

Eine Frage: Verwendest Du 7.0-Release, oder 7-stable (d.h.
RELENG_7, *nicht* RELENG_7_0)? Das kann einen großen Unter-
schied machen. Falls Du noch die Release laufen hast,
würde ich empfehlen, möglichst auf ein aktuelleres 7-stable
zu updaten. Wichtig ist dabei, nicht Deine alte Kernel-
Configuration beizubehalten, sondern von GENERIC auszugehen
(oder zumindest GENERIC mit Deiner eigenen Config verglei-
chen), damit Du z.B. in den Genuss von SCHED_ULE kommst.
Der alte SCHED_4BSD funktioniert in FreeBSD 7 offenbar
nicht mehr korrekt.

> Jetzt wird die Tastatur sogar erst ca. 10 Sekunden nach dem
> kompletten Systemhochlauf erkannt, aber die Modelldaten sind
> nicht mehr da:
>
> ums0: <vendor 0x0430 product 0x0100, class 0/0, rev 1.00/1.02,
> addr 2> on uhub1
> ums0: 3 buttons.
> ukbd0: <vendor 0x0430 product 0x0005, class 0/0, rev 1.00/1.02,
> addr 3> on uhub1
> kbd1 at ukbd0

Huch. Kann ich hier gar nicht reproduzieren. Auf einem
aktuellen 7-stable:

ums0: <Semi Tech Semi Tech PS/2 Keyboard - PS/2 Mouse, class 0/0, rev 1.01/0.01, addr 2> on uhub0
ums0: 3 buttons and Z dir.

(Das ist ein Logitech TrackMan Marble FX, der an einem
PS/2-USB-Adapter hängt. Eine USB-Tastatur verwende ich
nicht, daher kann ich das leider nicht vergleichen.)

> In der Datei /usr/src/sys/dev/usb/usbdevs stehen die richtigen
> Einträge aber drin.

Das hat nichts zu sagen, die Device-Strings werden direkt
vom Gerät abgefragt (per USB-Protokoll). Das macht die
Funktion usbd_get_string_desc() in sys/dev/usb/usb_subr.c.

Du könntest mal versuchsweise den Kernel mit USBDEBUG
compilieren und schauen, was das für Ausgaben produziert.

> In Deutschland hat man ja auch gern deutsche Tastaturunter-
> stützung.

Dazu kann ich leider nicht viel sagen, da ich US-Belegung
vorziehe. Eine speziell abgewandelte US-Belegung, mit der
ich auch deutsche und andere Sonderzeichen bequem erreichen
kann, setze ich per keymap="..." in /etc/rc.conf. Ich habe
noch nie versucht, eine Keymap im Kernel einzucompilieren.

Evtl. kann das jemand anders kommentieren, des das auch
macht.

> Das neue X.org ist katastrophal.

Kann ich ebenfalls nicht bestätigen. Bei mir hat sich
nichts nennswert verändert. Allerdings kann das auch sehr
von der jeweiligen Graphikhardware abhängen, und somit vom
Xorg-Treiber. Ich habe sowohl Nvidia als auch ATI immer
vermieden ... Ich glaube, damit habe ich mir einiges an
Ärger erspart.

> Zunächst braucht es für den
> Start (Systemhochlauf, anschl. xdm oder automatisches Login
> als Standardbenutzer) etwa 10 Sekunden.

Bei mir weniger als 2 Sekunden. Welche(n) Treiber hast Du
installiert? --> pkg_info | grep xf86-video

Falls mehr als einen, entferne bitte alle, die Du nicht
brauchst. Möglicherweise ruft der X-Server beim Starten
die Probe-Routinen aller Treiber auf, was natürlich eine
Weile dauert.

> Meine bisherigen Vorstellungen, daß man, wenn man
> schon einen 21"-Monitor hat, sich auch an 1400x1050 erfreuen
> können sollte, werden enttäuscht, es ist nur noch 1152x864
> möglich, auch mit Zwangsmitteln (PreferredMode und Modeline)
> ist nichts machbar, da bleibt dann sogar der Rechner stehen.

$ uname -rs
FreeBSD 7.0-STABLE-20080714
$ xdpyinfo | grep dim
  dimensions: 1400x1050 pixels (296x222 millimeters)
$ pciconf -lv | grep -i graph
    device = '82915GM/GMS, 82910GML Integrated Graphics Device'
    
> FreeBSD 5.x + XFree86 4.3 hat 1400x1050 in 2 Sekunden geschafft,
> aber FreeBSD 7.x + X.org 7.3_1 mit xorg-server 1.4_4,1 kann
> nur noch 1152x864 und braucht dafür 10 Sekunden - was für ein
> Fortschritt.

Was die geringe Auflösung betrifft, müsste man sich die
Xorg-Configuration und das Xorg-Logfile anschauen, um das
näher zu untersuchen. Ohne weitere Infos kann man da
leider nicht helfen.

Du solltest auf jeden Fall mal prüfen, dass Dein X-Server
tatsächlich den betreffenden Hardware-Treiber verwendet
und nicht etwa den VESA-Treiber. Letzteres könnte evtl.
einige der Symptome erklären.

> Einen Interaktionsbonus gibts noch, wenn man von
> X auf eine Textmoduskonsole umschaltet (Ctrl-Alt-PF1) und dann
> wieder zurück (Alt-PF9), da geht nämlich die Num-Lock-LED aus.

Die Funktionen habe ich bei mir disabled, kann ich daher
leider nicht kommentieren. (Evtl. ein anderer ...)

> Auch mißfällt, daß von der
> Standardeinstellung, die Komma-Taste im numerischen Block der
> Tastatur mit dem Punkt zu belegen, Abstand genommen worden ist.

Hm, ich dachte, das wäre nur bei US-Belegung die Standard-
einstellung. Bei mir kommt dort auch ein Punkt. Ich nahm
eigentlich an, dass bei deutscher Tastaturbelegung dort ein
Komma gesendet wird, was ja im Deutschen der übliche Dezi-
maltrenner ist.

Davon abgesehen kann man aber die Tastaturbelegung beliebig
ändern. Ich verwende dafür immer das GUI von xkeycaps
(ports/x11/xkeycaps).

> Gimp braucht jetzt mehr als 20 Sekunden zum Start

Bei mir ca. 8 bis 10 Sekunden nach einem Reboot. Er
braucht halt ein bisschen, um den ganzen Plugin-Krempel
zu laden. Startet man ihn dann erneut (d.h. die Dateien
sind im Cache), sind es so 3 bis 4 Sekunden. Das war
bei mir aber schon immer so; auch mit älteren Versionen
war es nicht nennenswert schneller.

> und reagiert auch dann nur sehr langsam.

Sicher, dass Du keinen VESA-Treiber verwendest?
Und welchen Scheduler verwendest Du -- ULE oder 4BSD?
Hast Du im Kernel sonst irgendwelche Abweichungen vom
Standard (GENERIC) gemacht, z.B. »options HZ« oder so?

> Ein Rechtsklick, der das Menü hervorbringen soll, wird
> gefolgt von 3 Sekunden Wartezeit.

Kann ich absolut nicht reproduzieren. Das Menü erscheint
praktisch sofort.

> Wenn
> man etwas drucken will, beschwert sich lpstat (offenbar ein
> Teil von CUPS, was soll ich damit?),

Ich glaube, CUPS ist eine Abhängigkeit von gimp-print,
welches wiederum eine Abhängigkeit vom gimp selbst ist.
Da ich CUPS nicht brauche, habe ich daher nicht den Meta-
Port gimp installiert, sondern nur gimp-app. Dann hat
man auch gimp-print nicht. Mir ist eh nicht 100% klar,
wozu man gimp-print braucht. Ich kann auch ohne diesen
Port drucken.

> daß keine Verbindung zum
> Server bestünde. Sollte man es dann wagen, etwas drucken zu
> wollen, füllen sich Systemkonsole und Systemlog mit Meldungen,
> abwechselnd und in einer Menge, daß dmesg "umkippt" und dauernd
> eine neue messages-Datei angelegt werden muß:
>
> lpt0: [GIANT-LOCKED]
> lpt0: [ITHREAD]
>
> Der Asudruck erfolgt jedoch.

Seltsam. Obiges erscheint eigentlich nur beim Proben bzw.
Attachen des lpt-Treibers. Wenn Du das dauern bekommst,
heißt das, der Treiber wird standig attacht und wieder
detacht. Ist mir ein Rätsel. Hast Du lpt(4) fest im
kernel oder als Modul geladen? Bekommst Du sonstige
Meldungen auf der Console, im dmesg oder im Syslog, die
etwas mit lpt zu tun haben?

> Und der Datei-Öffnen-Dialog nimmt fast
> den ganzen Bildschirm (s.o.) ein; ich möchte nicht wissen, wie
> der bei 800x600 aussehen soll. In ihm fehlt auch eine beque-
> me Möglichkeit, ".." zu machen, bisher war ".." Teil der
> Verzeichnisliste, jetzt muß man mit der Maus ganz schön viel
> Weg zurücklegen.

Da solltest Du Dich bei den Gimp-Leuten beschweren; das hat
nichts mit FreeBSD zu tun.

Ich persönlich habe nichts gegen den Öffnen-Dialog. Da
mein Display eine relativ hohe Auflösung hat (120 dpi),
finde ich die Größe sogar recht angenehm. Aber es wäre
sicherlich nicht verkehrt, wenn man das in den Preferences
konfigurieren könnte, falls man ein Display mit geringerer
Auflösung hat.

> Den Vogel schießt allerdings Opera 9 ab. Bisher mein allerliebster
> Lieblingsbrowser, hat sich Opera mittlerweile zu einer Quelle
> steten Genervtseins entwickelt, weil es soooo lahmarschig gewor-
> den ist.

Kann ich auch nicht ganz nachvollziehen. Ich habe gerade
letzte Woche auf 9.51 aktualisiert, und er ist nicht lang-
samer geworden. Einige Funktionen sind spürbar schneller
geworden (z.B. das Suchen in der History, die ich bei mir
auf maximale Größe eingestellt habe). Genau so war das
eigentlich auch bei Updates in der Vergangenheit.

> Es produziert sogar Systemlasten von bis zu 100%, dann
> geht nix mehr.

Huch. Das passiert bei mir nur, wenn eine Flash-Anwendung
mal in eine Endlosschleife gerät und 100% CPU verbrät, was
aber am Flash liegt und nicht am Opera (aus diesem Grund
habe ich Flash auch nur für wenige, ausgewählte Sites
enabled).

Verwendest Du den native Opera oder Linux-Opera? Wenn
letzteres, hast Du eine aktuelle Linux-Umgebung (d.h.
den entsprechenden linux_base-Port)?

> Sehr unangenehm ist auch die
> scheinbar immer mehr um sich greifende Angewohnheit, daß jedes
> Programm seine eigenen Mauszeiger mitbringen müsse. Wenn Opera
> Seiten lädt, wird der Mauszeiger weiß (pfui) mit einer Sanduhr
> dran (doppelpfui), wie sieht denn das aus?! Ach ja, und Gimp
> ist mit der Mauszeigerwahl auch nicht derade ein Vorbild.

Wie Du schon schreibst, ist das Sache der Anwendungen.
Bei Opera ist mir das nie so richtig aufgefallen ... erst
als Du es geschrieben hast, habe ich es überhaupt bemerkt.
Insofern kann ich nicht behaupten, dass es mich stört.
Bei Gimp kann man den Tool-Cursor in den Preferences
irgendwo konfigurieren.

Theoretisch kannst Du auch die Cursor-Graphiken von Xorg
editieren. Das hilft natürlich nur, wenn Anwendungen nicht
ihre eigenen Cursor-Bitmaps definieren, aber ich glaube,
zumindest Opera verwendet Cursors aus dem Standard-Set.

> Ich stelle fest, daß ich mich meistens mit Firefox durch das
> WWW bewege. Mit fehlen zwar die Mausgesten (kann man aber wohl
> nachinstallieren) sowie einige Konfigurationsfeinheiten, aber
> Firefox ist schneller als Opera ("gefühlte Schnelligkeit")

Nach meienr Erfahrung ist das Gegenteil der Fall.

> und kann auch bessere Ausdrucke erstellen.

Kann ich nicht kommentieren, da ich noch nie mit Firefox
gedruckt habe. Die Ausdrucke von Opera haben für meine
Zwecke bisher immer genügt.

> Und Firefox scheint eine Tastenkombination zum Beenden
> (Ctrl-Q beispielsweise) zu fehlen,

Ich habe mit die Windowmanager-Funktion Window-Quit auf
Meta-Q gelegt (Meta ist bei mir die linke Windows-Taste).
Daher kann ich damit _jede_ Anwendung schließen, egal was
sie für eigene Hotkeys hat. Das ist sozusagen das Pendant
zu Alt-F4 unter MS-Windows.

> Und versuche mal einer, mplayer zu compilieren (gmencoder,
> gmplayer, mencoder, mplayer).

Ich habe letzten Freitag mplayer und mencoder compiliert
(im Zuge eines allgemeinen Ports-Updates). Lief völlig
problemlos durch. Allerdings ohne die gm*-Sachen; die
verwende ich nicht.

> Das hängt sich an libgiofam.so auf, soweit ich sehe,
> ein Teil des Gnome- bzw. Gtk2-Rattenschwanzes.

Die ist bei mir nicht installiert, daher kann ich das
nicht kommentieren.

> Unangenehm bei mplayer ist auch, daß die Spulkontrolle
> sich merkwürdig verhält.

Funktioniert bei mir wie eh und je.

> gleichzeitig sieht man, wie der Film vorspult, meist gepaart
> mit glucksenden Tonfragmenten. So kennt man das, so ist es in
> Ordnung.

Ähm, »glucksende Tonfragmente«? So kenne ich das eigent-
lich nicht (und fände ich auch nicht in Ordnung). Bei mir
verhält sich der Ton völlig normal.

> Jetzt ist es aber anders: Der Film wird zwar vorge-
> spult, man hört es, aber der Verlaufsbalken bleibt bei seiner
> ursprünglichen Position stehen, das Bild auch. Und die mit
> der Taste "o" zuschaltbare Zeitanzeige ist auch weg.

Funktioniert bei mir alles wie gewohnt.

> Selbst XMMS scheint nicht mehr so richtig zu funktionieren.

Verwende ich nicht.

> Der Midnight Commander war bisher mein wichtigstes Werkzeug
> zur Dateiadministration,

Verwende ich nicht; mein wichtigstes Werkzeug zur Datei-
administration ist die Shell (insbesondere die zsh).

> Und Sylpheed, mein bevorzugter E-Mail-Klient, hat auch eins
> mit der erwähnten Gtk2-Klatsche übergebraten gekriegt, was
> dazu geführt hat, daß es größer geworden ist (hinsichtlich
> des Konsums von Bildschirmplatz) und langsamer. Da kommt
> kaum noch Freude auf.

Ich verwende Sylpheed nicht, aber manche X-Anwendungen
richten sich nach der Display-Auflösung, um die Größe von
Fonts und Dialogen anzupassen. Prüfe mal, ob die Auflösung
bei Dir korrekt eingestellt ist (xdpyinfo | grep resol).
Vielleicht gibt es auch eine Möglichkeit, dies in Sylpheed
oder in GTK (oder was auch immer Du als WIndowmanager oder
»Desktop« verwendest) zu konfigurieren. Manche Programme
haben auch Kommandozeilen-Optionen dafür (-font, -fn o.ä.).

> So, nun habe ich mich erstmal ausgeheult. :-) Falls jemand
> Korrekturvorschläge oder sonstige Kommentar hat, nur zu, sie
> sind mir stets willkommen.

Ein paar Infos wären noch nützlich ...
 - Genaue FreeBSD-Version (uname -a).
 - Scheduler (ULE oder 4BSD).
 - Am besten wäre es, die komplette Kernel-Config zu sehen.
 - /etc/make.conf und /etc/src.conf (sofern vorhanden)
 - Xorg.conf
 - Evtl. Xorg.log irgendwo hochladen (ist zum Posten hier
   in der Liste evtl. etwas zu lang).
 - rc.conf, sysctl.conf etc. (sofern potentiell wichtige
   und/oder nicht-standard-Sachen drinstehen).

Mehr fällt mir auch gerade nicht ein.

Achja, eins noch: Ich gehe davon aus, dass Du nach dem
Update auf FreeBSD 7 _alle_ Ports gelöscht und neu instal-
liert hast, richtig?

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"With sufficient thrust, pigs fly just fine.  However, this
is not necessarily a good idea.  It is hard to be sure where
they are going to land, and it could be dangerous sitting
under them as they fly overhead." -- RFC 1925
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 15 Jul 2008 - 10:26:19 CEST

search this site