• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Mal wieder: Dell Latitude macht keinen Reboot

F

Freddie62

Guru
Seit einiger Zeit nutze ich OS12.2. Da der Kernel 3.6 eine bessere Unterstützung für die Intel-Grakas mitbringt, verwende ich zur Zeit den Kernel kernel-desktop-3.6.4-1.1.x86_64. Mit diesem Kernel bleibt der Schleppi bei "setting system for reboot" hängen und friert ein. Wenn ich z.B. den Kernel kernel-default-3.4.11-2.16.1.x86_64 nutze, passiert das nicht. Wo liegt der große Unterschied? :???:
das Ganze ist mir auch schon bei OS12.1 aufgefallen. Wenn man den Kernel aus dem OSS oder Update-Repo verwendet hat, ging der Reboot, bei den anderen Kerneln nicht. :irre:
Das verstehe, wer will! Jemand eine Idee?

CU

Freddie
 
RME

RME

Advanced Hacker
Hallo,

Kürzlich (http://www.linux-club.de/viewtopic.php?f=41&t=115855#p735053) hattest Du noch geschrieben:
Inzwischen habe ich OS 12.2 installiert und nutze denselben Kernel wie zuvor (3.5.3-1-desktop). Unter OS12.2 funktioniert der Reboot, unter 12.1 nicht. Kann also nicht am Kernel gelegen haben.
Zum Vergrößern anklicken....
Aktuell schreibst Du:
Seit einiger Zeit nutze ich OS12.2. Da der Kernel 3.6 eine bessere Unterstützung für die Intel-Grakas mitbringt, verwende ich zur Zeit den Kernel kernel-desktop-3.6.4-1.1.x86_64. Mit diesem Kernel bleibt der Schleppi bei "setting system for reboot" hängen und friert ein. Wenn ich z.B. den Kernel kernel-default-3.4.11-2.16.1.x86_64 nutze, passiert das nicht. Wo liegt der große Unterschied?
Zum Vergrößern anklicken....
Du hast demnach:
Code: 
                      OS 12.1       OS 12.2       OS 12.2
                      Kernel A      Kernel A      Kernel B
Reboot funktioniert:  nein          ja            nein
Es gibt eben noch andere Faktoren, z.B. "System V" vs. "systemd"

Gruss,
Roland
 
OP
F

Freddie62

Guru
Unter 12.1 genau wie unter 12.2 nutze ich systemd. Unter 12.1 konnte das Problem beim Kernel 3.2 durch den Kernelparamter "Reboot=P" behoben werden. Angeblich lag das Problem am (Dell-)BIOS des Laptop, daher war dieser Parameter erforderlich. In späteren Kerneln wurde diese (Dell-spezifische)Option entfernt und ließ sich daher nicht mehr nutzen. Witzigerweise funktioniert bei meinem Sohn (Dell Latitude 5520 OS12.1 und derselben BIOS-Version und Kernel 3.4..) der Reboot. Allerdings hat er einen I7, ich nur einen I5. So ganz schlau werde ich nicht daraus. Entweder werden bei den Kerneln aus dem Standard-Repo irgendwelche Optionen oder was auch immer nicht mitkompiliert, oder mein Schleppi hat ein Problem. Ich werde wohl wieder den normalen Desktop-Kernel installieren. Alles Andere ist einfach nur nervig.

CU Freddie
 
S

spoensche

Moderator
Teammitglied
Butter bei die Fische, was sagt
Code: 
dmesg
? Was sagt
Code: 
egrep "WW|EE" /var/log/Xorg.0.log
?
 
OP
F

Freddie62

Guru
Hier nun die Butter: ;)
dmesg
und
Code: 
egrep "WW|EE" /var/log/Xorg.0.log
[    26.595] Current Operating System: Linux linux-6trf.site 3.6.4-1-desktop #1 SMP PREEMPT Sun Oct 28 21:11:41 UTC 2012 (0a37c3b) x86_64
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    26.595] (WW) The directory "/usr/share/fonts/URW/" does not exist.
[    26.595] (WW) The directory "/usr/share/fonts/misc/sgi" does not exist.
[    26.680] (II) Loading extension MIT-SCREEN-SAVER
[    26.686] (WW) Falling back to old probe method for fbdev
[    26.686] (WW) Falling back to old probe method for vesa

CU Freddie
 
RME

RME

Advanced Hacker
mesg schrieb:
Code: 
[    0.193861] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored

[    0.671197] hub 1-0:1.0: USB hub found 
[    0.671201] hub 1-0:1.0: 2 ports detected

[    0.681165] hub 2-0:1.0: USB hub found 
[    0.681168] hub 2-0:1.0: 2 ports detected

[    1.087709] hub 1-1:1.0: USB hub found 
[    1.087929] hub 1-1:1.0: 6 ports detected

[    1.305182] hub 2-1:1.0: USB hub found 
[    1.305377] hub 2-1:1.0: 6 ports detected
Zum Vergrößern anklicken....

Bezüglich dem ersten: siehe bitte hier > http://www.linux-club.de/viewtopic.php?f=41&t=116843#p737558

Der Rest: poste bitte noch
Code: 
lsusb
was hängt alles and dem Hub? Hast Du Deine "Kernel-Variationen" auch ohne den Hub getestet?

Gruss,
Roland
 
S

spoensche

Moderator
Teammitglied
Ich fang dann mal an: ;)

Code: 
[    0.000000] ACPI Warning: 32/64 FACS address mismatch in FADT - two FACS tables! (20120711/tbfadt-394)
[    0.000000] ACPI BIOS Bug: Warning: 32/64X FACS address mismatch in FADT - 0xCAFE4E40/0x00000000CAFE4D40, using 32 (20120711/tbfadt-521)
[    0.187211] mtrr: your CPUs had inconsistent variable MTRR settings
[    0.187212] mtrr: probably your BIOS does not setup all CPUs.
[    0.187212] mtrr: corrected configuration.

FADT= Fixed ACPI Description Table.
FACS = Firmware ACPI Control Structure.
Das ist gar nicht gut. Wenn es schon bei den ACPI Tabellen zu Fehlern kommt, dann ist i.d.R. auch die Funktionalität einiger Hardwarekomponenten beinträchtigt und weitere Fehler sind garantiert. Wie bei dir z.B. die Settings der CPU und da die FADT auch im Powermanagement mit involviert ist, wird es beim PM auch Probleme geben.

Code: 
[    2.301204] fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
[    0.973082] ACPI: Invalid Power Resource to register!

Dies ist die Ursache für deine Probleme mit der Intelgrafik. Wie es dann so kommt hat der Fehler in der FADT Table auch Auswirkung auf die Grafik. Die Warnings bezügl. des Konflikts zwischen SystemIO und PMIO1 sagen dann alles.

Erstelle mal die Datei /etc/modprobe.d/blacklist-vesa.cfg mit dem Inhalt
Code: 
blacklist vesafb
.
Möglicherweise können wir den Grafikfehler so beheben. Wenn du kein aktuelles BIOS auf deinem Laptop hast, dann solltest du es unbedingt aktualisieren.

Es wäre hilfreich, wenn du den Kernel mit den Bootoptionen
Code: 
acpi.debug_layer=0x2 acpi.debug_level=0xffffffff
booten könntest. (Achtung da wird eine Menge Output erzeugt) und danach die erneut die Ausgabe von
Code: 
dmesg
postest.
 
OP
F

Freddie62

Guru
So, der VesaFB ist geblacklisted. Hier noch die Ausgabe von dmesg[/u] nach Ändern der Kernelparameter.
An dem (internen) USB-Hub ist übrigens zumindest von außen nichts angeschlossen. Ich vermute mal, daß die WLAN-Karte, das Modem, das Touchpad, etc. daran hängen.
http://www.linux-club.de/viewtopic.php?f=41&t=116843#p737558 habe ich noch nicht durchgeführt. Werde ich mir mal genauer ansehen.

CU Freddie

Edit: Das BIOS ist aktuell (Version A03). Habe ich wegen ähnlicher Probleme mit 12.1 schon auf den neuesten Stand gebracht.
 
S

spoensche

Moderator
Teammitglied
Das kann nicht der gesamte Ouput von dmesg sein. Was ich da allerdings sehe ist definitiv nicht normal. Boote bitte mal mit
Code: 
acpi.debug_layer=0xffffffff acpi.debug_level=0x2
und poste dann bitte erneut die Ausgabe von dmesg.

Poste bitte auch die vollständige Ausgabe von
Code: 
hwinfo
 
OP
F

Freddie62

Guru
So, hier nun die Ausgabe von dmesg nochmal. Für alle Fälle habe ich anschließend nochmal ein dmesg durchgeführt.
Die Ausgabe von hwinfo habe ich ebenfalls in nopaste.info gestellt, da sie etwas länger ist, wobei ich den EPROM-dump (ca. 1 Million Zeilen) gelöscht habe.

CU Freddie
 
S

spoensche

Moderator
Teammitglied
Freddie62 schrieb:
Die Ausgabe von hwinfo habe ich ebenfalls in nopaste.info gestellt, da sie etwas länger ist, wobei ich den EPROM-dump (ca. 1 Million Zeilen) gelöscht habe.
Zum Vergrößern anklicken....

Zum Glück hast du die wichtigen nicht gelöscht. Ich habe im Dump der ACPI DSDT Table etwas entdeckt, was mir so noch nicht über den Weg gelaufen ist. Es wird von Win98 bis Win7 irgendwas unterstützt bzw. total zerhackstückelt, was vermutl. dein Problem verursacht.

Du müsstest jetzt folgendes durchführen:
1. acpidump und iasl installieren

Code: 
acpidump -o acpidump
acpixtract -a acpidump
iasl -d *.dat

Und die DSDT.dsl zur Verfügung stellen
 
OP
F

Freddie62

Guru
Du meintest wohl eher : acpi_osi=LINUX ;)
Hat aber auch keinen Erfolg gebracht. Er macht immer noch keinen Reboot und hängt bei
Code: 
[   86.997127] Restarting system

CU Freddie
 
OP
F

Freddie62

Guru
Hier die Ausgabe von dmesg. Ich habe das Gefühl, daß einige Dinge etwas besser laufen, insbesondere das Mousepad. Ganz sicher bin ich mir allerdings nicht. Anscheinend sind auch die acpi-Probleme die dmesg anzeigt weniger geworden.

CU Freddie
 
S

spoensche

Moderator
Teammitglied
Das ist bei dir aber auch ganz schön verkorkst. Da ich leider kein AML kann, ich am Code keine Hand anlegen. Du hast jetzt noch folgende Möglichkeiten, um das Problem in den Griff zu bekommen:

1. Kompilieren der DSDT und sie dem Kernel beim Boot mitgeben
2. Nach einem weiteren BIOS Update umsehen
3. Schritt für Schritt einzelne Funktionenim BIOS deaktivieren und testen, ob es besser wird.
4. Nach einem BIOS Mod suchen.
5. Support vom Hersteller

Ich selber habe für mein Notebook einen BIOS Mod verwendet, um gesperrte Funktionen freigeschaltet zu bekommen, damit ich auf die Hitzeentwicklung Einfluss nehmen konnte. In deinem Fall würde ich allerdings die Punkte einzeln durchgehen.
 
OP
F

Freddie62

Guru
Erst mal vielen Dank für Deine Bemühungen und den Support. Villeicht hilft das ja auch Anderen mit einem ähnlichen Problem schon mal etwas weiter.
Ich werde mich bei nächster Gelegenheit mal dranmachen, die Bios-Funktionen durchzuprobieren. Eigenartigerweise läuft OS12.1 bei meinen Sohn ja ohne Probleme. Der hat dasselbe BIOS, aber, soweit ich weiß, auch den aktuellen Kernel. Wenn er demnächst kommt, werden wir 12.2 installieren. Mal sehen wie das bei Ihm funktioniert. Ich hatte allerdings unter 12.1 dieselben Probleme wie jetzt. Wie gesagt, ich habe das Gefühl, daß das Keypad besser läuft. Eine Zeit lang mußte ich eine Maus nutzen, da ich mit dem Keypad nicht mehr arbeiten konnte (Statt Cursor bewegen Arbeitsflächenwechsel, oder nur sehr langsame Bewegung, Verschieben per Cursor nicht möglich, etc.). Mal abwarten.

CU Freddie
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben