Fedora 19

D

dirkk

Active member
Themenstarter
Registriert
15 Apr. 2006
Beiträge
1.507
Längst Zeit für die Eröffnung, auch wenn F19 noch nicht Release ist. Aber viele nutzen es ja schon und offenbar erfolgreich. Ich selbst habe derzeit keinen beklagenswerten Punkt, so gut war es eigentlich noch nie. :)
 
Zuletzt bearbeitet:
Code: 
$ ls -l /dev/tty{USB?,ACM?}
ls: Zugriff auf /dev/ttyUSB? nicht möglich: Datei oder Verzeichnis nicht gefunden
crw-rw----. 1 root dialout 166, 0 27. Jul 15:00 /dev/ttyACM0
crw-rw----. 1 root dialout 166, 1 27. Jul 15:00 /dev/ttyACM1
crw-rw----. 1 root dialout 166, 2 27. Jul 15:00 /dev/ttyACM2
Code: 
$ cat /sys/class/tty/ttyACM2/device/interface 
H5321 gw Mobile Broadband GPS Port


buddabrod schrieb:
Ich habe keine Ahnung, was für ein Gerät du da hast. Wenn du es aber zur Laufzeit einstöpseln kannst, würde ich das tun
Zum Vergrößern anklicken....
Was meinst du? Oben habe ich ja geschrieben, es ist eine (eingebaute) Ericcson F5321gw.
 
maximal mkdev .. aber mit touch ist gut :D

Alternativ! Wenn das Programm WIRKLICH! nu auf diesem einen /dev/ lauscht, und das Device sich als was anderes anmeldet wäre ein "ln" zu probieren.

Wenn das klappt, könnte man sich ne UDEV-Regel schreiben. Oder du schreibst das Programm soweit um das man das /dev/ variable machen kann.

Grüße
 
dirkk schrieb:
Was meinst du? Oben habe ich ja geschrieben, es ist eine (eingebaute) Ericcson F5321gw.
Zum Vergrößern anklicken....
Mein neustes TP ist ein T400 ohne irgendsowas, ich kenne die Geräte nicht. Das hab ich damit gemeint :)

Hast du mal gpsd -b ausprobiert? Deine Ausgabe von vorher ist aber seltsam, weil du ja das ACM2 als Gerät angibst, aber sich die Fehlermeldung auf USB0 bezieht?

Edit: bei -D5 muss auch bei deinem gpsd -N Aufruf jeder Fehler direkt im Terminal angezeigt werden, sonst ist noch was faul.
 
Habe in einer Konfig das dortige Gerät auskommentiert und stattdessen auf /dev/ttyACM2 gesetzt.
Code: 
cat /etc/sysconfig/gpsd
OPTIONS="-n"
#DEVICE="/dev/ttyUSB0"
DEVICE="/dev/ttyACM2"
USBAUTO="true"
Dies funkioniert zwar auch nicht, produziert aber ganz andere (Fehler-) Meldungen:
Code: 
Jul 27 15:29:36 gatto kernel: [   83.493173] pps_ldisc: PPS line discipline registered
Jul 27 15:29:36 gatto kernel: [   83.493508] pps pps0: new PPS source acm2
Jul 27 15:29:36 gatto kernel: [   83.493514] pps pps0: source "/dev/ttyACM2" added
Jul 27 15:29:36 gatto gpsd[713]: gpsd:ERROR: PPS ioctl(TIOCMIWAIT) failed: 25 Inappropriate ioctl for device
Jul 27 15:29:39 gatto kernel: [   87.254167] usb 3-4: reset high-speed USB device number 2 using xhci_hcd
Jul 27 15:29:39 gatto kernel: [   87.266632] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88040623e680
Jul 27 15:29:39 gatto kernel: [   87.266645] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88040623e6c0
Jul 27 15:29:39 gatto kernel: [   87.266651] xhci_hcd 0000:00:14.0: xHCI xhci_drop_endpoint called with disabled ep ffff88040623e700
[...]
Jul 27 15:29:39 gatto kernel: [   87.302521] pps pps0: removed
Sagt das jemandem etwas?

EDITH: Nein, auf der Konsole wird mir trotz der Optionen kein Fehler angezeigt.

EDITH2: Auch die Option -b ändert nichts.
 
Zuletzt bearbeitet:
Eventuell ist ttyACM2 nicht die richtige Schnittstelle der Karte für GPS? Du könntest auch mal die beiden anderen ausprobieren, vieleicht entspricht ttyACM0 dem erwarteten ttyUSB0.
 
Nochmal zum Thema ungewollter Reboot nach Shutdown, da ich das Problem mit dem X230 immer noch habe: der Rechner geht für ca. 1 Sek. aus und schlatet sich dann wieder ein. Passiert so im Schnitt ca. jedes 5.-10. mal, was recht lästig ist.

simpel schrieb:
von meinem Verständnis her handelt es sich eher um einen Hardwarefehler.
Zum Vergrößern anklicken....
Was für eine Art Hardwarefehler wäre Deiner Ansicht nach denkbar?

Hat noch jemand ein derartiges Problem?
 
Hallo dirkk, ich hab die Probleme nicht und ja auch ein X230 mit Fedora 19. Deswegen kann ich mir nicht vorstellen, dass es was mit Wifi zu tun hat. Ich hatte zuerst die Intel 2200 und jetzt seit ein paar Wochen die Intel 6205, aber einfach so ein Reboot ist mir bis jetzt noch nie passiert... sehr seltsam.... kommt das einfach so oder bei längerer Laufzeit? Ich hatte Mal sehr eigenartige Probleme mi Tlp und USB_AUTOSUSPEND=1 festgestellt. Deshalb hab ich da etliche Geräte herausgenommen wie z.B. BT, UMTS und noch ein paar andere externe Geräte. Übrigens läuft bei mir aktuell auch kein GPS. Geht die H5321gw überhaupt unter Windows problemlos?
 
Hallo kalibari,

danke für die Rückmeldung. Reboot.....ich weiss nicht, ob du es missverstanden hast: ich will den Rechner normal ausschalten (also aus dem Gnome heraus herunterfahren); er fährt dann auch normal runter und *manchmal* (ca. jedes 5-10. mal) schaltet sich der Rechner nach ca. 1 Sekunde wieder ein (und fährt dann hoch). Im normalen Betrieb macht er nicht von selbst einen Reboot (falls du es so verstanden hast). Das Problem scheint aber prinzipiell beim X230 bekannt zu sein, wie ja auch die verlinkte Anleitung und einige weitere Internetseiten zu dem Thema zeigen. (Die Seite im Arch-Wiki ist für User des X230 insgesamt von Interesse.) Wie fährst du dein X230 runter? Hast du spezielle Bootoptionen?

Wenn du mal eine Lösung für das GPS weisst, gib mir bitte bescheid.
 
Zuletzt bearbeitet:
@dirkk: was genau hast Du von der Anleitung implementiert? Das Skript /etc/rc.local.shutdown samt .service? Wenn tatsächlich das Runtime PM schuld sein sollte (das ist das was rc.local.shutdown ausschaltet), dann dürfte es mit TLP nur am Akku passieren.
 
Ja, das Skript samt Service (ergänzt durch den dort fehlenden "Installation" Abschnitt samt Target und abgelegt unter /etc). Wenn ich im Büro oder zuhause bin, habe ich den Rechner eigentlich fast immer am Netz. Und dann ist es auch passiert. (Also: Es passiert im Akkubetrieb *und* im Netzbetrieb.) TLP habe ich immer in Betrieb.
 
Nein, bei mir geht der Shutdown immer problemlos, ohne weitere Einstellungen, RUNTIME_PM_ALL, hatte ich übrigens testweise auch mal aktiviert und es hat eigenartige Phänomene hervorgebracht (weiß gar nicht mehr welche) deswegen habe ich es ausgeschalten, es ist ja auch glaub per default aus.
 
Nebenbei: was ist denn das beste Target für den Service, um etwaige Nebenwirkungen zu vermeiden? Ich habe "multi-user" gewählt. Oder sollte es besser "reboot" sein?
 
dirkk schrieb:
Also: Es passiert im Akkubetrieb *und* im Netzbetrieb.
Zum Vergrößern anklicken....
Wie gesagt: das Skript bewirkt nur im Akkubetrieb eine Änderung (Rücknahme) der von TLP vorgenommenen Spareinstellungen. Von daher kann der Ursachenzusammenhang nicht stimmen.
 
Hmm.... Tatsache ist aber, dass ich bisher ca. 30-40 Shutdowns ohne Probleme hatte. Vorher hätte ich da mit Sicherheit einige Reboots gehabt.
 
linrunner, wahrscheinlich hast du recht gehabt. Ich habe jetzt folgendes festgestellt (bezieht sich jetzt nur auf Netzbetrieb): wenn ich während der Session kein Suspend/Resume hatte, dann ist Shutdown okay, und anscheinend immer. (Keine Ahnung, ob das Skript da schon etwas zu begetragen hat). ABER: wenn ich zwischendurch ein Suspend/Resume hatte, dann funktioniert Shutdown nicht. UND: dies ist dann anscheinend IMMER so.

Jetzt habe ich versucht, den Service so abzuändern, dass er NACH einem Resume ausgeführt wird. Das gelingt mir aber nicht. Hat jemand einen Plan, wie das mit systemd geht? Oder bin ich damit sowieso auf dem Holzweg, und der Service nützt dann nichts mehr?
 
dirkk schrieb:
linrunner, wahrscheinlich hast du recht gehabt. Ich habe jetzt folgendes festgestellt (bezieht sich jetzt nur auf Netzbetrieb): wenn ich während der Session kein Suspend/Resume hatte, dann ist Shutdown okay, und anscheinend immer. (Keine Ahnung, ob das Skript da schon etwas zu begetragen hat). ABER: wenn ich zwischendurch ein Suspend/Resume hatte, dann funktioniert Shutdown nicht. UND: dies ist dann anscheinend IMMER so.
Zum Vergrößern anklicken....

Da ich STR eigentlich sehr selten verwende, könnte es sein, dass mir das Problem deshalb noch nie aufgefallen ist. Hast du jetzt RUNTIME_PM_ALL in Tlp aktiviert oder nicht? Ich werd Mal bei Gelegenheit testen, ob ich das nachstellen kann.
 
Einstellungen in TLP:
Code: 
RUNTIME_PM_ON_AC=on
RUNTIME_PM_ON_BAT=auto
RUNTIME_PM_ALL=0

Verstehe ich richtig: statt des Skripts könnte ich auch
Code: 
RUNTIME_PM_ON_BAT=on
einstellen, das würde exakt das gleiche bewirken?
 
Ich hatte jetzt verschiedene Kombinationen mit/ohne Netzteil/Akku getestet und konnte den Fehler nicht nachstellen. Um in den STR zu gehen hatte ich einfach den Deckel zu und ca 5s später wieder aufgeklappt.
Schalte doch einfach Mal TLP ab, nimm eventuell die Kernel Bootoptionen raus und alles notwenidge aus der rc.local und teste Mal ob der Fehler noch da ist.

P.S. meine Info das es nicht an der Intel 2200 liegen kann muss ich dann auch zurücknehmen da der Fehler unter Bedingungen auftritt, die ich garantiert nie mit meiner alten Karte getestet hab.
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben