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

openSUSE 11.4 32bit friert ein

Da es sich bei deinem Problem um ein ACPI Problem handelt, ist die Ausgabe von
Code:
grep -i acpi
interessanter. Die Meldung hatte ich gestern auch, allerdings bei einer anderen Distri und Kernel 3.0.
 
Hier:
Code:
# dmesg |grep -i acpi
[    0.000000]  BIOS-e820: 000000006ff80000 - 000000006ff8e000 (ACPI data)
[    0.000000]  BIOS-e820: 000000006ff8e000 - 000000006ffd0000 (ACPI NVS)
[    0.000000] ACPI: RSDP 000fbcf0 00024 (v02 ACPIAM)
[    0.000000] ACPI: XSDT 6ff80100 00064 (v01 _ASUS_ Notebook 20100311 MSFT 00000097)
[    0.000000] ACPI: FACP 6ff80290 000F4 (v03 031110 FACP1627 20100311 MSFT 00000097)
[    0.000000] ACPI: DSDT 6ff80490 08A53 (v01  A1478 A1478000 00000000 INTL 20060113)
[    0.000000] ACPI: FACS 6ff8e000 00040
[    0.000000] ACPI: APIC 6ff80390 0005C (v01 031110 APIC1627 20100311 MSFT 00000097)
[    0.000000] ACPI: MCFG 6ff803f0 0003C (v01 031110 OEMMCFG  20100311 MSFT 00000097)
[    0.000000] ACPI: ECDT 6ff80430 00055 (v01 031110 OEMECDT  20100311 MSFT 00000097)
[    0.000000] ACPI: OEMB 6ff8e040 00072 (v01 031110 OEMB1627 20100311 MSFT 00000097)
[    0.000000] ACPI: HPET 6ff8a490 00038 (v01 031110 OEMHPET  20100311 MSFT 00000097)
[    0.000000] ACPI: SLIC 6ff8a4d0 00176 (v01 _ASUS_ Notebook 20100311 MSFT 00000097)
[    0.000000] ACPI: SSDT 6ff8a650 000D3 (v01 A M I  POWERNOW 00000001 AMD  00000001)
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: PM-Timer IO Port: 0x808
[    0.000000] ACPI: Local APIC address 0xfee00000
[    0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[    0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x81] disabled)
[    0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[    0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level)
[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[    0.000000] Using ACPI (MADT) for SMP configuration information
[    0.000000] ACPI: HPET id: 0x8300 base: 0xfed00000
[    0.008799] ACPI: Core revision 20110413
[    0.037717] PM: Registering ACPI NVS region at 6ff8e000 (270336 bytes)
[    0.038441] ACPI: bus type pci registered
[    0.043016] ACPI: EC: EC description table is found, configuring boot EC
[    0.045902] ACPI: Executed 3 blocks of module-level executable AML code
[    0.054655] ACPI: Interpreter enabled
[    0.054664] ACPI: (supports S0 S3 S4 S5)
[    0.054699] ACPI: Using IOAPIC for interrupt routing
[    0.057114] PCI: MMCONFIG at [mem 0xe0000000-0xefffffff] reserved in ACPI motherboard resources
[    0.066352] [Firmware Bug]: ACPI: BIOS _OSI(Linux) query ignored                                                                                                                             
[    0.068230] ACPI: EC: GPE = 0xe, I/O: command/status = 0x66, data = 0x62                                                                                                                     
[    0.068566] ACPI: No dock devices found.                                                                                                                                                     
[    0.068574] PCI: Using host bridge windows from ACPI; if necessary, use "pci=nocrs" and report a bug                                                                                         
[    0.068749] ACPI: PCI Root Bridge [PCI0] (domain 0000 [bus 00-ff])
[    0.075203] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[    0.075630] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
[    0.075708] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE4._PRT]
[    0.075767] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCE5._PRT]
[    0.075927]  pci0000:00: Requesting ACPI _OSC control (0x1d)
[    0.075932]  pci0000:00: ACPI _OSC request failed (AE_NOT_FOUND), returned control mask: 0x1d
[    0.075935] ACPI _OSC control for PCIe not granted, disabling ASPM
[    0.087825] ACPI: PCI Interrupt Link [LNKA] (IRQs 4 7 *10 11 12 14 15)
[    0.087945] ACPI: PCI Interrupt Link [LNKB] (IRQs 4 7 10 *11 12 14 15)
[    0.088067] ACPI: PCI Interrupt Link [LNKC] (IRQs 4 *7 10 11 12 14 15)
[    0.088188] ACPI: PCI Interrupt Link [LNKD] (IRQs 4 7 *10 11 12 14 15)
[    0.088309] ACPI: PCI Interrupt Link [LNKE] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[    0.088430] ACPI: PCI Interrupt Link [LNKF] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[    0.088506] ACPI: PCI Interrupt Link [LNKG] (IRQs *4 7 10 11 12 14 15)
[    0.088582] ACPI: PCI Interrupt Link [LNKH] (IRQs 4 7 10 11 12 14 15) *0, disabled.
[    0.089330] PCI: Using ACPI for IRQ routing
[    0.094271] pnp: PnP ACPI init
[    0.094296] ACPI: bus type pnp registered
[    0.094656] pnp 00:00: Plug and Play ACPI device, IDs PNP0a03 (active)
[    0.094922] system 00:01: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.095148] pnp 00:02: Plug and Play ACPI device, IDs PNP0200 (active)
[    0.095256] pnp 00:03: Plug and Play ACPI device, IDs PNP0b00 (active)
[    0.095395] pnp 00:04: Plug and Play ACPI device, IDs PNP0303 PNP030b (active)
[    0.095555] pnp 00:05: Plug and Play ACPI device, IDs SYN0a13 SYN0a00 SYN0002 PNP0f03 PNP0f13 PNP0f12 (active)
[    0.095610] pnp 00:06: Plug and Play ACPI device, IDs PNP0800 (active)
[    0.095710] pnp 00:07: Plug and Play ACPI device, IDs PNP0c04 (active)
[    0.095819] pnp 00:08: Plug and Play ACPI device, IDs PNP0103 (active)
[    0.096496] system 00:09: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.096732] system 00:0a: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.096869] system 00:0b: Plug and Play ACPI device, IDs PNP0c02 (active)
[    0.097401] system 00:0c: Plug and Play ACPI device, IDs PNP0c01 (active)
[    0.097677] pnp: PnP ACPI: found 13 devices
[    0.097679] ACPI: ACPI bus type pnp unregistered
[    1.439940] ACPI: acpi_idle registered with cpuidle
[    1.453171] ACPI: Thermal Zone [TZ00] (37 C)
[    5.991446] ACPI: Lid Switch [LID]
[    5.991601] ACPI: Sleep Button [SLPB]
[    5.991695] ACPI: Power Button [PWRB]
[    5.991796] ACPI: Power Button [PWRF]
[    6.065563] ACPI: Deprecated procfs I/F for AC is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
[    6.065697] ACPI: AC Adapter [AC0] (off-line)
[    6.297167] acpi device:05: registered as cooling_device1
[    6.297444] ACPI: Video Device [VGA] (multi-head: yes  rom: no  post: no)
[    6.399991] ACPI: Deprecated procfs I/F for battery is loaded, please retry with CONFIG_ACPI_PROCFS_POWER cleared
[    6.400065] ACPI: Battery Slot [BAT0] (battery present)
[    7.531556] asus_wmi: Backlight controlled by ACPI video driver
[ 2804.010813] ACPI: Preparing to enter system sleep state S4
[ 2804.039045] ACPI: Waking up from system sleep state S4



Danke
 
Mal abgesehen von dem fehlgeschlagenen Request (ist kein wirkliches Problem), sind die Meldung alle ok und es sollten keine Freezer mehr auftreten.
 
Leider tritt das Problem wieder auf. Ich habe heute openSUSE 12.1 64bit installiert. Bisher ist es nur einmal eingefroren. Die zu der Zeit laufende Software war KDE selbst, Konversation, Pidgin und Opera.

Noch irgendwelche Ideen?

Danke
 
Mal ganz anders gefragt: Was für ein Kernel läuft da
Code:
uname -a
und welche/r Grafikkarte/Treiber ist da installiert?

CU Freddie
 
Freddie62 schrieb:
Mal ganz anders gefragt: Was für ein Kernel läuft da
Code:
uname -a
Code:
Linux tux.DIR-615 3.1.0-1.2-desktop #1 SMP PREEMPT Thu Nov 3 14:45:45 UTC 2011 (187dde0) x86_64 x86_64 x86_64 GNU/Linux

und welche/r Grafikkarte/Treiber ist da installiert?
Modell: ATI Radeon HD 3200 Graphics
2D-Treiber: radeon
3D-Treiber: Unbekannt Gallium (7.11)



Danke
 
Es gab da mal eine Menge Probleme mit Einfrieren beim Kernel 2.6.37 und Nvidia. Das war aber mit dem 2.6.38er Kernel erledigt. Von dergleichen mit dem 3.1er Kernel habe ich bisher nichts gelesen. Ich habe hier auch ein System in einer ähnlichen Konfiguration, aber mit installiertem ATI-Treiber. Bisher habe ich kein Einfrieren beobachtet. Hattest Du dieses Verhalten auch mit dem Standard-Kernel der 11.4?

CU Freddie
 
Ja, das passierte auch mit dem Standardkernel. Nachdem ich aber auf 3.0 geupdatet hatte, ging es einige Zeit. Ich glaube dass es mit KMail zusammenhing, denn gestern, bevor ich 12.1 installiert hatte, ist das Netbook erst kurz nach Start von KMail hängen geblieben. KMail brauchte auch sonst immer 30-60 Sekunden bevor es erst benutzbar war – dank Mailinglisten, Threadsortierung und eben 30 Mails und mehr, wenn ich es am Tag zum ersten Mal startete.
 
Also ich hatte auch "willkürliche" Freezez bei meinem Desktop-PC kürzlich.... bei mir war der Grund wirklich der RAM (obwohl memtest auch keine errors zeigte). Habe alle 4 RAM Riegel durch neue ausgetauscht und nun sind die Freezes weg. Evtl. hast Du ja andere RAM-Riegel rumliegen, die du testen könntest?
 
Nein, leider nicht. Normalen RAM ja, aber nicht für Laptops. :/ Hmm... Bisher ist das Netbook aber noch nicht wieder eingefroren.
 
So, es ist wieder eingeforen innerhalb von 1 Stunde. Eine Ausgabe beim Booten die mir auffiel:
Code:
[   13.041574] SP5100 TCO timer: mmio address 0xfec000f0 already in use
Kann man damit wohl etwas anfangen?

Der ganze neue Log ist hier: http://susepaste.org/67691166

Sollte ich noch einmal memtest86+ drüberlaufen lassen?


Danke,

Gruß
Ctwx

p.s.: Ich habe einige Einstellungen mit "powertop" übernommen. Kann es sein, dass diese eventuell das Notebook zum einfrieren bringen?

Nachtrag, 23:08 Uhr
Das Netbook läuft nun seit 8 Stunden und 14 Minuten im memtest86+, 7 (fast 8) komplett Durchläufe ohne Fehler. Eigentlich hätte es doch abstürzen müssen wenn es keine Softwarekomponente wäre oder? Ich mein, wenn er RAM tatsächlich defekt wäre, dann hätte memtest dort doch sicherlich schon drauf zugegriffen und ebenfalls einen Absturz verursacht?

Sollte ich mal versuchen KDE laufen zu lassen um ausschließen zu können, dass es eine KDE Komponente ist? Ggf. auch einen anderen Kernel und ggf. vielleicht sogar ein mal ein BSD System? Diese Einfrieren geht mir echt auf die Nerven, nicht zuletzt weil ich das Gerät nicht mitnehmen kann, wenn ich weiß, dass es zwischenzeitlich einfach einfriert.
Eingeschickt hatte ich es schon einmal wegen den Abstürzen, aber es konnten keine Mängel festgestellt werden. Nun ja..

Nachtrag, 22.11.2011, 16:22 Uhr
Wie es aussieht friert das Netbook auch unter GNOME ein. Heißt offenbar, dass es nicht an KDE liegt. Nagut, dann probiere ich als nächstes mal ein BSD-System aus, schauen ob es da auch passiert.

Nachtrag, 22.11.2011, 20:52 Uhr
Ich habe nun FreeBSD 8 mit Gnome 2 installiert. Bisher ist das Netbook noch nicht eingefroren, ich lasse es aber mal laufen...
 
Seit gestern habe ich wieder openSUSE 12.1 x64 mit KDE installiert. Nach einigen Stunden Testlauf sah es erst sehr gut aus, jedoch ist das Gerät heute nach etwa einer halben Stunde abgestürzt. Allerdings habe ich eine neue Entdeckung gemacht: Ich war dabei per scp Daten übers WLAN zu kopieren.

Zurzeit läuft das Netbook mit einem LAN-Kabel da ich prüfen möchte ob es eventuell ein defekter WLAN-Chip ist – das war bei meinem ersten Netbook leider auch ein Problem, jedoch bekam ich da wenigstens einen Kernel-Panic.
Kennt ihr zufällig noch eine Methode wie ich prüfen könnte ob es am WLAN liegt? Wo würde so etwas geloggt werden, falls es geloggt wird?



Danke,

Gruß
Ctwx
 
Teste mal Dein W-Lan Chip mit Live Systemen.

Frieren die auch ein, hast Du den Übeltäter. Du kannst den W-Lan Chip auch am Netbook ausschalten.

Und bitte Teste das netbook auch mit Knoopix und anderen Distries. Gerade eee PC´s machen gerne m,al Zicken.

Ich spreche da aus erfahrung, da ich die Dinger für einen Kunden Updaten muß.


MfG


Peter
 
Danke ich teste es mal. Habe die letzten zwei Tage mal das Netbook mit openSUSE 12.1 laufen lassen, bestimmt 10 Stunden. Habe nun grml per USB an. Bisher läuft es noch. :) Es lief in der Zeit aber die ganze Zeit mit angeschlossenen Stromkabel. Deshalb meine folgende Annahme →

Sagt mal, könnte so ein Freeze eventuell durch den Standby-Mechanismus verursacht werden? Seit Kernel, ich glaube 3.0.8, funktioniert an dem Gerät weder Suspend to Disk noch Suspend to Ram. Es "friert" dann einfach ein und es ist nur noch ein brutales Abschalten möglich.
Ein Kernel Panic scheint nicht die Uhrsache zu sein, denn habe ich ein Terminal an laufen lassen mit "sudo tail -c /var/log/messages" sodass ich sehe wenn etwas passiert. Keine Fehlerausgabe oder sonstiges.


Danke,

Gruß
Ctwx
 
Ctwx schrieb:
Danke ich teste es mal. Habe die letzten zwei Tage mal das Netbook mit openSUSE 12.1 laufen lassen, bestimmt 10 Stunden. Habe nun grml per USB an. Bisher läuft es noch. :) Es lief in der Zeit aber die ganze Zeit mit angeschlossenen Stromkabel. Deshalb meine folgende Annahme →

Sagt mal, könnte so ein Freeze eventuell durch den Standby-Mechanismus verursacht werden? Seit Kernel, ich glaube 3.0.8, funktioniert an dem Gerät weder Suspend to Disk noch Suspend to Ram. Es "friert" dann einfach ein und es ist nur noch ein brutales Abschalten möglich.
Ein Kernel Panic scheint nicht die Uhrsache zu sein, denn habe ich ein Terminal an laufen lassen mit "sudo tail -c /var/log/messages" sodass ich sehe wenn etwas passiert. Keine Fehlerausgabe oder sonstiges.


Danke,

Gruß
Ctwx

Ja der Standby-Mechanismus kann auch die Ursache sein.

MfG

Peter
 
Okay, es scheint sich wirklich um kein Kernel Panic zu handeln. Ich habe als Kernelparameter "panic=30" hinzugefügt. Das Gerät startete sich nicht neu. Auch mit Alt+Druck+B passiert nichts. Es wirkt wirklich wie "Suspend". Ich habe schon gesucht, aber leider nichts genaues für die aktuelle openSUSE Version, das scheint sich irgendwie geändert haben. Gibt es eine Möglichkeit Suspend komplett zu deaktivieren ohne es zu deinstallieren?

p.s.: Ich glaube ich werde das Gerät einschicken. :/ Irgendwie habe ich nur Ärger mit Netbooks - das ist schon das dritte Netbook das ich habe; das erste hatte einen defekten WLAN-Chip, das zweite mochte nicht-Windows nicht (Touchpad blockierte trotz vorhandener Treiber oO) und das hier nun ja, ihr könnt es ja lesen.
 
Ctwx schrieb:
Okay, es scheint sich wirklich um kein Kernel Panic zu handeln. Ich habe als Kernelparameter "panic=30" hinzugefügt. Das Gerät startete sich nicht neu. Auch mit Alt+Druck+B passiert nichts. Es wirkt wirklich wie "Suspend". Ich habe schon gesucht, aber leider nichts genaues für die aktuelle openSUSE Version, das scheint sich irgendwie geändert haben. Gibt es eine Möglichkeit Suspend komplett zu deaktivieren ohne es zu deinstallieren?

p.s.: Ich glaube ich werde das Gerät einschicken. :/ Irgendwie habe ich nur Ärger mit Netbooks - das ist schon das dritte Netbook das ich habe; das erste hatte einen defekten WLAN-Chip, das zweite mochte nicht-Windows nicht (Touchpad blockierte trotz vorhandener Treiber oO) und das hier nun ja, ihr könnt es ja lesen.

Klingt jetz bissel schräge, aber versuche es mal damit:

„zypper rm systemd-sysvinit”

"Falls aus irgendeinem Grund systemd bei Ihnen nicht funktionieren sollte, können Sie immer noch das alte Sys-V-Init verwenden indem sie F5 im Bootloader drücken. Falls Sie permanent das alte Startsystem verwenden wollen, führen sie einfach „zypper rm systemd-sysvinit” aus. Wir bieten auch wieder grub2 als einen optionalen Bootloader an. Obwohl wir noch nicht ganz mit Grub2 als Ersatz für das aktuelle Grub zufrieden sind, ermuntern wir unsere Nutzer, es einmal auszuprobieren und wollen sicher gehen, dass es für Entwickler verfügbar ist."

"systemd-sysvinit” kommt irgend wie mit meinen 2008ter Bios net klar. Könnte so auch bei Dir der Fall sein.

Da Du ja das Gerät neu aufgesetzt hast, kann man so den Fehler schneller einengen.


MfG


Peter
 
Die Idee ist nicht schlecht, aber leider fror das Netbook auch schon mit openSUSE 11.4 ein, als systemd ja noch nicht auf dem System war. :/
 
Ctwx schrieb:
Die Idee ist nicht schlecht, aber leider fror das Netbook auch schon mit openSUSE 11.4 ein, als systemd ja noch nicht auf dem System war. :/

Und wie schaut es mit smartd aus? Der schoß mir meine Platten auch gerne ab. Der is bei mir zur Zeit aus und alle Platten laufen ohne Zicken.

Teste das auch mal, kann nicht schaden.


MfG

Peter
 
Oben