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

SuSE 10.1 auf Core Duo sorgt für hohe Prozessorlast.

d4h0nk

Newbie
Hallo zusammen,

ich habe hier nen neues Notebook, nen Fujitsu Celsius H240 mit nem T2600 Core Duo Prozessor (daher ist das im Thread Notebooks gelandet). Installiert ist SuSE 10.1
Nach Installation des SMP-Kernels warn beide Prozessoren ansprechbar, allerdings ist eine CPU generell mit dem events-Prozess zu über 90% ausgelastet. Der zwiete events-Prozess läuft anständig durch.

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
6 root 12 -5 0 0 0 R 94 0.0 19:49.98 events/0
7 root 10 -5 0 0 0 S 0 0.0 0:00.07 events/1

Habt Ihr Erfahrung damit und könnt mir

a) sagen, wer oder was event ist?
b) sagen, warum der sich ernsthaft über 90% zieht (und das konstant!)
c) sagen, warum man den nicht kicken kann (kein kill -9, killall oder was auch immer ist erfolgreich)
d) sagen, wie ich eine CPU wieder ans rennen bekomme?

Leider ist die Suche bei Google nicht wirklich erfolgreich (Suchegriffe wie Linux + events + Prozess liefern extrem viel Datenmüll) und ich bin mit meinem Latein am Ende.

Ach ja, Kernelversion ist 2.6.16.21-0.13-bigsmp.

Any suggestions? Für Hilfe sehr dankbar wäre
d4h0nk
 

Greedy

Member
Hi,

hast Du mittels Konsole mal den Befehl "top" eingegeben und geschaut welcher Prozess so viel frisst?

Kannst ja mal einen Auszug posten.
Mir fiel schon mal auf, dass das System inkonsistent wird, wenn der Grafiktreiber falsch ist bzw. die xorg.conf falsche Konfigurationen aufweist. Das führte kürzlich bei mir zu einer permanenten Auslastung von 100%.

Grund war, dass ich den nvidia-Treiber installiert hatte und nach dem YOU - Update ein neuer Kernel drauf war und dann hat es gekracht. Nach Neuinstallation des Nvidia Treibers war alles wieder im grünen Bereich....
 
OP
D

d4h0nk

Newbie
Hi,

wie ich bereits gepostet hatte: der Prozess "events" verursacht den Ärger... Auszug aus "top" siehe oben.

Aber ich glaube, ich bin inzwischen einen kleinen Schritt weiter. Beim Systemstart fummelte mir dieser komischen KNetworkManager gerne mal dazwischen... den habe ich sehr spontan per YasT entfernt. Seitdem bekommt die Kiste hier keine IP-Adresse mehr vom DHCP-Server zugewiesen (noch nicht mehr Etherreal analysiert, aber gem. EInstellung im YasT soll er sie sich automatisch holen).

Wenn ich nun mehrmals nen "rcnetwork -restart" mache, dann ist die Maschine gewillt, sich früher oder später eine IP zu ziehen. Doch genau in dem Moment scheint "events" auf 100% CPU-Last zu springen und hört dann damit auch nich mehr auf.

Chipsatz der LAN-Karte ist von Marvel (genaue Version poste ich später), ist hier im System als Fujitsu 88E8055 PCI-E Gigabit Ethernet Controller.

Da fäujitsu 88E8055 PCI-E Gigabit Ethernet Controllerllt mir nochwas in dem Zusamenhang ein: Für den Zugrff zur Firma nutze ich OpenVPN in der aktuellsten Version, welches ja auch noch ein Ethernet-Device erzeugt. Kann das den Ärger verursachen? Werde das Gerät später nochmal entfernen und dann Rückmeldung geben.

So long,

d4h0nk
 
OP
D

d4h0nk

Newbie
Hi,

thx 4 hint, aber da sieht es relativ ruhig aus.

Jul 28 09:15:52 muellerxp [acpid]: completed event "battery CMB2 00000080 00000001"
Jul 28 09:19:57 muellerxp [acpid]: received event "battery CMB2 00000080 00000001"
Jul 28 09:19:57 muellerxp [acpid]: notifying client 3075[0:0]
Jul 28 09:19:57 muellerxp [acpid]: notifying client 3330[0:0]
Jul 28 09:19:57 muellerxp [acpid]: notifying client 3843[0:0]
Jul 28 09:19:57 muellerxp [acpid]: completed event "battery CMB2 00000080 00000001"
Jul 28 09:21:09 muellerxp [acpid]: received event "battery CMB2 00000080 00000001"
Jul 28 09:21:09 muellerxp [acpid]: notifying client 3075[0:0]
Jul 28 09:21:09 muellerxp [acpid]: notifying client 3330[0:0]
Jul 28 09:21:09 muellerxp [acpid]: notifying client 3843[0:0]
Jul 28 09:21:09 muellerxp [acpid]: completed event "battery CMB2 00000080 00000001"
Jul 28 09:22:06 muellerxp [acpid]: received event "battery CMB2 00000080 00000001"
Jul 28 09:22:06 muellerxp [acpid]: notifying client 3075[0:0]
Jul 28 09:22:06 muellerxbzw. YasT p [acpid]: notifying client 3330[0:0]
Jul 28 09:22:06 muellerxp [acpid]: notifying client 3843[0:0]
Jul 28 09:22:06 muellerxp [acpid]: completed event "battery CMB2 00000080 00000001"


Habe nun nochmal ein wenig getestet... scheint definitiv an der Netzwerkkarte zu liegen... denn dann (und nur dann) wenn ich eine neue IP-Adresse via DHCP bekomme und die entsprechenden Skripte hier systemseitig laufen, nur dann taucht das Problem auf.

Daraus resultieren 2 Fragen:
a) Warum bekomme ich nicht automatisch (vie von DHCP vorgesehen) ne IP sondern muss das System via rcnetwork restart bzw. YasT dazu überreden?
b) warum kommt das System mit der Marvel Yukon nicht zurecht?

Werde erstmal die neuen Treiber (bzw. die dafür vorgesehenen) einspielen... dann mehr.

Greetz
d4h0nk
 

oc2pus

Ultimate Guru
d4h0nk schrieb:
Daraus resultieren 2 Fragen:
a) Warum bekomme ich nicht automatisch (vie von DHCP vorgesehen) ne IP sondern muss das System via rcnetwork restart bzw. YasT dazu überreden?
b) warum kommt das System mit der Marvel Yukon nicht zurecht?

da solltest du mal im "TCP/IP-Netzwerke und Internetzugang" fragen bzw schauen ob es da nicht schon eine Lösung gibt. Denn ich denke hier liest kein Netzwerk-Spezi mit ....

und auch das WLAN Forum ist ein guter Kandidat, da gerade dort in den letzten Tagen diese Marvel-Probleme vorkamen
 
Welchen Yukon-Treiber verwendest du denn? sk98lin oder den neueren skge? Zu ändern ist das in YaST mit der Netzwerkkarten-Konfiguration unter Hardware-Details.
 
OP
D

d4h0nk

Newbie
war: sky2, ist nun wieder sky2, allerdings auf nem gepatchten 2.6.17er Kernel. Damit rennt es nun auch. *freu*
Und nun: hat jemand Ahnung von WLAN-Karten (atheros Chipsatz)? Laughing

Thx a lot 4 help. Wenn jemand dasselbe Problem habe sollte:

1.) Kernel 2.6.17 runterladen,
2) Kernel patchen
3) Feuer


Tipps hierzu:

1) http://support.fujitsu-siemens.com/forum/viewtopic.php?p=47932&sid=b2b7069e1d337ab6300fc2cef6d39358

2) http://www.joachim-reichel.de/misc/e8110/

Hiermit patchen:
--- linux-2.6.17.orig/drivers/net/sky2.c 2006-07-03 21:36:07.000000000 +0200
+++ linux-2.6.17/drivers/net/sky2.c 2006-07-09 13:39:49.000000000 +0200
@@ -181,8 +182,10 @@
{
u16 v;

- if (__gm_phy_read(hw, port, reg, &v) != 0)
+ if (__gm_phy_read(hw, port, reg, &v) != 0) {
printk(KERN_WARNING PFX "%s: phy read timeout\n", hw->dev[port]->name);
+ WARN_ON(1);
+ }
return v;
}

@@ -1679,12 +1682,12 @@
u16 istatus, phystat;

spin_lock(&sky2->phy_lock);
- istatus = gm_phy_read(hw, port, PHY_MARV_INT_STAT);
- phystat = gm_phy_read(hw, port, PHY_MARV_PHY_STAT);
-
if (!netif_running(dev))
goto out;

+ istatus = gm_phy_read(hw, port, PHY_MARV_INT_STAT);
+ phystat = gm_phy_read(hw, port, PHY_MARV_PHY_STAT);
+
if (netif_msg_intr(sky2))
printk(KERN_INFO PFX "%s: phy interrupt status 0x%x 0x%x\n",
sky2->netdev->name, istatus, phystat);





Und ab dafür!

Läuft nun Netzwerktechnisch alles sehr gut. Ich muss nun nur noch den AppArmor wieder zum laufen bekommen... komisches Ding. Wo komst das eigentlich her? Sowas gab es doch früher noch nicht..
 
Das gehört hier nicht hin, aber AppArmor wird ein wenig kompliziert werden, wenn du keinen SuSE-Kernel verwendest. Du musst dann das src.rpm zum SuSE-Kernel herunterladen und installieren und danach aus dem Verzeichnis /usr/src/packages/SOURCES die entsprechenden Patches extrahieren und auf deinen Kernel anwenden.
 
Oben