Re: Kernel-Oops??
Am Dienstag, 17. Oktober 2006 19:14 schrieb Peter Kuechler: Hallo, wo bin ich denn da wieder reingetreten??? -Ausschnitt aus syslog-- Oct 17 18:01:24 pelle kernel: irq 21: nobody cared (try booting with the irqpoll option) Leider ist es doch noch nicht vorbei:-( Nachdem ich meine neu SATA-Karte eingebaut habe (Siehe DVD brennen mit SATA) und alles getestet habe hat alles funktioniert. Dann habe ich die akuellen SID-Updates eingespielt und den Kernel von 2.6.18 auf 2.6.18.1 geändert. Darauf hin ist er heute Nacht beim Technen des gleichen Films wie immer wieder stehen geblieben. Aber was solls, immerhin habe ich jetzt noch Potential zum suchen, hab natürlich von der laufenden Version ein Backup gemacht;-) Mals sehen, wie das ausgeht. -- mfg Peter Küchler
Re: Kernel-Oops??
Am Mittwoch, den 18.10.2006, 17:41 +0200 schrieb Andreas Kroschel: * Peter Kuechler: Er läuft jetzt 9:19 Stunden am Stück, davon die ersten ca. 5 Stunden mit Volldampf. Es besteht also Hoffnung. Ich habe das gerade hinter mir¹, allerdings nicht mit Kernel-oops, sondern wort- und logloses Einfrieren. Anfangs Das hatte ich zwischen drinn auch schon mal, ein kurzer leiser Knacks, und alles hat gestanden:-( nur mit nvidia-Treiber unter Last, dann auch ohne Last, dann auch mit nv, am Ende auch ohne X unter Last (ebenfalls Videos konvertieren). ¹ Wenn dieser Nebensatz zutrifft – ich konvertiere gerade das dritte Video, und die Kiste läuft –, dann war es das Netzteil. Das würde ich bei solchen Dingen immer vor einem MB-Tausch erwägen, da der Umbauaufwand sehr viel geringer ist. Aber hoffentlich brauchst Du diesen Tip erst gar nicht. Tips kann man immer gebrauchen;-) das Netzteil hatte ich auch schon im Verdacht, hätte ich dann auch noch getauscht. Jetzt die neusten Meldungen von meiner Front: Rechner ist wieder von heute Morgen durchgelaufen, mit 3D-Treiber! Wieder den gleichen Film gerechnet, 4,5 Stunden lang, bis jetzt nach ca 8 Stunden alles OK. Ich habe übrigens gestern Abend die Kartensteckplätze von Netzwerkkarte und DVB-T Karte gewechselt. Ob es das war??? -- mfg Peter Küchler Systemadministrator Planungsverband Ballungsraum Frankfurt/Rhein-Main Tel.: 069-2577-1301 [EMAIL PROTECTED] www.pvfrm.de
Re: Kernel-Oops??
On Thu, Oct 19, 2006 at 03:29:11PM +0200, Peter Kuechler wrote: Am Mittwoch, den 18.10.2006, 17:41 +0200 schrieb Andreas Kroschel: * Peter Kuechler: Er läuft jetzt 9:19 Stunden am Stück, davon die ersten ca. 5 Stunden mit Volldampf. Es besteht also Hoffnung. Ich habe das gerade hinter mir¹, allerdings nicht mit Kernel-oops, sondern wort- und logloses Einfrieren. Anfangs Das hatte ich zwischen drinn auch schon mal, ein kurzer leiser Knacks, und alles hat gestanden:-( nur mit nvidia-Treiber unter Last, dann auch ohne Last, dann auch mit nv, am Ende auch ohne X unter Last (ebenfalls Videos konvertieren). ¹ Wenn dieser Nebensatz zutrifft – ich konvertiere gerade das dritte Video, und die Kiste läuft –, dann war es das Netzteil. Das würde ich bei solchen Dingen immer vor einem MB-Tausch erwägen, da der Umbauaufwand sehr viel geringer ist. Aber hoffentlich brauchst Du diesen Tip erst gar nicht. Tips kann man immer gebrauchen;-) das Netzteil hatte ich auch schon im Verdacht, hätte ich dann auch noch getauscht. Jetzt die neusten Meldungen von meiner Front: Rechner ist wieder von heute Morgen durchgelaufen, mit 3D-Treiber! Wieder den gleichen Film gerechnet, 4,5 Stunden lang, bis jetzt nach ca 8 Stunden alles OK. Ich habe übrigens gestern Abend die Kartensteckplätze von Netzwerkkarte und DVB-T Karte gewechselt. Ob es das war??? Das sind immer diese witzigen Kleinigkeiten auf die man selten eine eindeutige Antwort findet ;-) Vielleicht ist heute der Raum, in dem der Rechner steht, 1 Grad kühler. Paul signature.asc Description: Digital signature
Re: Kernel-Oops??
* Peter Kuechler: das Netzteil hatte ich auch schon im Verdacht, hätte ich dann auch noch getauscht. Ich hatte noch zwei Indizien mehr: Die Standbyspannung war dauerhaft über ¾ Volt zu niedrig, und nach einem Ab- und Wiedereinschalten des Netzteils per Kippschalter wollte der Rechner so fünf bis sechs deutliche Betätigungen des Einschalters, bevor er dann wirklich ansprang. Ich habe übrigens gestern Abend die Kartensteckplätze von Netzwerkkarte und DVB-T Karte gewechselt. Ob es das war??? Eventüll, wenn sich dadurch die Interrupt-Zuordnungen geändert haben. Andreas -- Just because the message may never be received does not mean it is not worth sending. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Kernel-Oops??
* Peter Kuechler: ## default kernel options for automagic boot options ## If you want special options for specific kernels use kopt_x_y_z ## where x.y.z is kernel version. Minor versions can be omitted. ## e.g. kopt=root=/dev/hda1 ro ^^ ## kopt_2_6_8=root=/dev/hdc1 ro ## kopt_2_6_8_2_686=root=/dev/hdc2 ro # kopt=root=/dev/sda1 ro,irqpoll -^ Ich habe es einfach mit dem Komma angeängt, ist das OK so? Nein, da muß ein Space hin. Kann ich eigentlich nach dem hochfahren irgendwo sehen mit welchen Komandozeilenparametern der Kernel gestartet wurde? cat /proc/cmdline Andreas -- If you sow your wild oats, hope for a crop failure. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Kernel-Oops??
Peter Kuechler [EMAIL PROTECTED] wrote: Ich habe es einfach mit dem Komma angeängt, ist das OK so? Eher nicht, Trennzeichen dürfte ein Leerzeichen sein. Aber mit grub kenne ich mich kaum aus. Kann ich eigentlich nach dem hochfahren irgendwo sehen mit welchen Komandozeilenparametern der Kernel gestartet wurde? $ dmesg |grep command Übrigens, jetzt wo ich weis worauf ich achten muß sehe ich, das vor jedem Absturz (die jetzt laufend kommen) diese Meldung kommt (immer irq 21). Danke schon mal, Rob -- The PROPER way to handle HTML postings is to cancel the article, then hire a hitman to kill the poster, his wife and kids, and fuck his dog and smash his computer into little bits. Anything more is just extremism. -- Paul Tomblin -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Kernel-Oops??
Am Mittwoch, den 18.10.2006, 08:44 +0200 schrieb Andreas Kroschel: * Peter Kuechler: ## default kernel options for automagic boot options ## If you want special options for specific kernels use kopt_x_y_z ## where x.y.z is kernel version. Minor versions can be omitted. ## e.g. kopt=root=/dev/hda1 ro ^^ ## kopt_2_6_8=root=/dev/hdc1 ro ## kopt_2_6_8_2_686=root=/dev/hdc2 ro # kopt=root=/dev/sda1 ro,irqpoll -^ Ich habe es einfach mit dem Komma angeängt, ist das OK so? Nein, da muß ein Space hin. Ok, danke, hab ich jetzt geändert! Kann ich eigentlich nach dem hochfahren irgendwo sehen mit welchen Komandozeilenparametern der Kernel gestartet wurde? cat /proc/cmdline Jo, hat funktioniert: pelle:/proc# cat /proc/cmdline root=/dev/sda1 ro,irqpoll Da war das Komma noch drin...:-( Ich hab e jetzt mal den Nvidia-Treiber weggelassen und den gleichen Rechenprozess wie immer gestartet (MainActor rechnet einen Film) Ich kontrolliere das vom Büro aus, bis jetzt läuft er noch;-) Dann werde ich die nächsten Tests machen und mich wieder hier melden. Bis dann, -- mfg Peter Küchler Systemadministrator Planungsverband Ballungsraum Frankfurt/Rhein-Main Tel.: 069-2577-1301 [EMAIL PROTECTED] www.pvfrm.de
Re: Kernel-Oops??
Am Mittwoch, den 18.10.2006, 08:39 +0200 schrieb Robert Grimm: Peter Kuechler [EMAIL PROTECTED] wrote: Ich habe es einfach mit dem Komma angeängt, ist das OK so? Eher nicht, Trennzeichen dürfte ein Leerzeichen sein. Aber mit grub kenne ich mich kaum aus. Ja, scheint so zu sein;-) Kann ich eigentlich nach dem hochfahren irgendwo sehen mit welchen Komandozeilenparametern der Kernel gestartet wurde? $ dmesg |grep command Hat auch funktioniert, danke! -- mfg Peter Küchler Systemadministrator Planungsverband Ballungsraum Frankfurt/Rhein-Main Tel.: 069-2577-1301 [EMAIL PROTECTED] www.pvfrm.de
Re: Kernel-Oops??
Am Dienstag, den 17.10.2006, 19:46 +0200 schrieb Andreas Pakulat: On 17.10.06 19:14:40, Peter Kuechler wrote: wo bin ich denn da wieder reingetreten??? Das nennt man Tretmine ;) Ja, ich glaube du hast den richtigen Ausdruck gefunden:-( aussieht hängt da der nvidia-Treiber drauf... Hat jemand eine Idee? Klaro: Schmeiss die Grafikkarte weg und mache deine Arbeit wieder mit PenPaper, die sind auch nach nem Absturz noch zu gebrauchen ;) Meinst du es ist die Karte? Das wäre nicht so schön... Hab jetzt erstmal den Nvidiatreiber weggelassen (siehe andere Mail dazu) -- mfg Peter Küchler Systemadministrator Planungsverband Ballungsraum Frankfurt/Rhein-Main Tel.: 069-2577-1301 [EMAIL PROTECTED] www.pvfrm.de
Re: Kernel-Oops??
Peter Kuechler: Am Mittwoch, den 18.10.2006, 08:39 +0200 schrieb Robert Grimm: Peter Kuechler [EMAIL PROTECTED] wrote: Kann ich eigentlich nach dem hochfahren irgendwo sehen mit welchen Komandozeilenparametern der Kernel gestartet wurde? $ dmesg |grep command Hat auch funktioniert, danke! Das funktioniert allerdings nur, so lange die ersten Meldungen noch im Ringpuffer für die Kernelmeldungen drinstehen. Laut 'man dmesg' gehen da nur 16k rein und das reicht nicht unbedingt, wenn da mal ein paar mehr Meldungen durchgehen. Also lieber /proc/cmdline merken. J. -- If all my friends had Playstations I would buy a Nintendo to prove my individuality. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: Kernel-Oops??
* Peter Kuechler: Ich hab e jetzt mal den Nvidia-Treiber weggelassen und den gleichen Rechenprozess wie immer gestartet (MainActor rechnet einen Film) Ich kontrolliere das vom Büro aus, bis jetzt läuft er noch;-) Die nvidia-Treiber sind derzeit eh mit Vorsicht zu betrachten: http://golem.de/0610/48414 Andreas -- Good night to spend with family, but avoid arguments with your mate's new lover. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Kernel-Oops??
Am Mittwoch, den 18.10.2006, 15:56 +0200 schrieb Andreas Kroschel: * Peter Kuechler: Ich hab e jetzt mal den Nvidia-Treiber weggelassen und den gleichen Rechenprozess wie immer gestartet (MainActor rechnet einen Film) Ich kontrolliere das vom Büro aus, bis jetzt läuft er noch;-) Die nvidia-Treiber sind derzeit eh mit Vorsicht zu betrachten: http://golem.de/0610/48414 Ach wie nett:-( Letzter Stand bis jetzt: Er läuft jetzt 9:19 Stunden am Stück, davon die ersten ca. 5 Stunden mit Volldampf. -- mfg Peter Küchler Systemadministrator Planungsverband Ballungsraum Frankfurt/Rhein-Main Tel.: 069-2577-1301 [EMAIL PROTECTED] www.pvfrm.de
Re: Kernel-Oops??
* Peter Kuechler: Er läuft jetzt 9:19 Stunden am Stück, davon die ersten ca. 5 Stunden mit Volldampf. Es besteht also Hoffnung. Ich habe das gerade hinter mir¹, allerdings nicht mit Kernel-oops, sondern wort- und logloses Einfrieren. Anfangs nur mit nvidia-Treiber unter Last, dann auch ohne Last, dann auch mit nv, am Ende auch ohne X unter Last (ebenfalls Videos konvertieren). ¹ Wenn dieser Nebensatz zutrifft – ich konvertiere gerade das dritte Video, und die Kiste läuft –, dann war es das Netzteil. Das würde ich bei solchen Dingen immer vor einem MB-Tausch erwägen, da der Umbauaufwand sehr viel geringer ist. Aber hoffentlich brauchst Du diesen Tip erst gar nicht. Andreas -- You will obey or molten silver will be poured into your ears. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Kernel-Oops??
Hallo, wo bin ich denn da wieder reingetreten??? -Ausschnitt aus syslog-- Oct 17 18:01:24 pelle kernel: irq 21: nobody cared (try booting with the irqpoll option) Oct 17 18:01:24 pelle kernel: [c0131af7] __report_bad_irq+0x2b/0x69 Oct 17 18:01:24 pelle kernel: [c0131cf6] note_interrupt+0x1c1/0x1fb Oct 17 18:01:24 pelle kernel: [c01312ca] handle_IRQ_event+0x21/0x49 Oct 17 18:01:24 pelle kernel: [c01313a4] __do_IRQ+0xb2/0xe8 Oct 17 18:01:24 pelle kernel: [c0104c0e] do_IRQ+0x43/0x51 Oct 17 18:01:24 pelle kernel: [c0103286] common_interrupt+0x1a/0x20 Oct 17 18:01:24 pelle kernel: [c029f8ec] acpi_pm_read+0x7/0xf Oct 17 18:01:24 pelle kernel: [c011e3da] do_gettimeofday+0x2d/0xca Oct 17 18:01:24 pelle kernel: [c022bcb3] copy_to_user+0x37/0x54 Oct 17 18:01:24 pelle kernel: [c011ad0d] sys_gettimeofday+0x1a/0x51 Oct 17 18:01:24 pelle kernel: [c01028ff] syscall_call+0x7/0xb Oct 17 18:01:24 pelle kernel: handlers: Oct 17 18:01:24 pelle kernel: [fa49b84e] (nv_kern_isr+0x0/0x64 [nvidia]) Oct 17 18:01:24 pelle kernel: Disabling IRQ #21 Oct 17 18:01:31 pelle kernel: NVRM: Xid (0001:00): 16, Head 0001 Count Oct 17 18:01:32 pelle kernel: NVRM: Xid (0001:00): 16, Head Count 0014c72e Oct 17 18:03:33 pelle syslogd 1.4.1#20: restart. -Ende Ausschnitt aus syslog-- In den Manuals zum Kernel steht, das es sich um ein kaputtes BIOS handelt. Nach dem Neustart hab ich mal in /proc/interrupts nachgesehen, so wie es aussieht hängt da der nvidia-Treiber drauf... Hat jemand eine Idee? Ich hatte in letzter Zeit mehrere Abstürze, hatte das im log aber übersehen:-( -- mfg Peter Küchler
Re: Kernel-Oops??
On 17.10.06 19:14:40, Peter Kuechler wrote: wo bin ich denn da wieder reingetreten??? Das nennt man Tretmine ;) aussieht hängt da der nvidia-Treiber drauf... Hat jemand eine Idee? Klaro: Schmeiss die Grafikkarte weg und mache deine Arbeit wieder mit PenPaper, die sind auch nach nem Absturz noch zu gebrauchen ;) SCNR Andreas -- You may get an opportunity for advancement today. Watch it! -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Kernel-Oops??
Peter Kuechler [EMAIL PROTECTED] wrote: -Ausschnitt aus syslog-- Oct 17 18:01:24 pelle kernel: irq 21: nobody cared (try booting with the irqpoll option) ^^^ Hast Du das schon ausprobiert? Rob -- In Linux werden mehr Sicherheitslücken gefunden. In Windows sind mehr Sicherheitslücken drin. -- Lutz Donnerhacke -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: Kernel-Oops??
Am Dienstag, 17. Oktober 2006 22:17 schrieb Robert Grimm: Peter Kuechler [EMAIL PROTECTED] wrote: -Ausschnitt aus syslog-- Oct 17 18:01:24 pelle kernel: irq 21: nobody cared (try booting with the irqpoll option) ^^^ Hast Du das schon ausprobiert? Ja, schon...bin mir aber nicht sicher, ob es funktioniert hat. Ich habe es in grub/menu.lst eingetragen, und zwar in der Zeile: [...] ## ## Start Default Options ## ## default kernel options ## default kernel options for automagic boot options ## If you want special options for specific kernels use kopt_x_y_z ## where x.y.z is kernel version. Minor versions can be omitted. ## e.g. kopt=root=/dev/hda1 ro ## kopt_2_6_8=root=/dev/hdc1 ro ## kopt_2_6_8_2_686=root=/dev/hdc2 ro # kopt=root=/dev/sda1 ro,irqpoll -^ Ich habe es einfach mit dem Komma angeängt, ist das OK so? Kann ich eigentlich nach dem hochfahren irgendwo sehen mit welchen Komandozeilenparametern der Kernel gestartet wurde? Übrigens, jetzt wo ich weis worauf ich achten muß sehe ich, das vor jedem Absturz (die jetzt laufend kommen) diese Meldung kommt (immer irq 21). Danke schon mal, -- mfg Peter Küchler
Re: Grund für Kernel Oops
Am 2005-03-10 06:32:29, schrieb Michael Ott:
Hallo Ihr!
Auf einem Testserver (Woody auf Sarge upgedatet und 2.4.27-Kernel)
bekomme ich folgenden Oops:
Mar 7 08:57:05 ipx10318 kernel: Unable to handle kernel paging request at
virtual address 00ae78aa
Mar 7 08:57:05 ipx10318 kernel: Process apache (pid: 803, stackpage=d31a3000)
Mar 7 08:57:05 ipx10318 kernel: Stack: d31a2000 c0116db0 d31a3f70 c014bd3c
cf909f20
Mar 7 08:57:05 ipx10318 kernel:0246 d31a2000 0064
Mar 7 08:57:05 ipx10318 kernel:c014c0cc d31a3fa8 d31a3fa4
d31a2000 bdf8 be08
Was könnte die Ursache dafür sein?
Um das herauszufinden benötigst du die Datei
/boot/System.map-version
und vor allem das notwendige Hintergrundwissen. Du
kannst dann die Calls in den kernel-source-version
wiederfinden, dann weiste wos gecrashed hat.
Memtest zeigt keinen Fehler im Arbeitsspeicher
CU
Michael
Greetings
Michelle
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSM LinuxMichi
0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com)
signature.pgp
Description: Digital signature
Grund für Kernel Oops
Hallo Ihr!
Auf einem Testserver (Woody auf Sarge upgedatet und 2.4.27-Kernel)
bekomme ich folgenden Oops:
Mar 7 08:57:05 ipx10318 kernel: Unable to handle kernel paging request at
virtual address 00ae78aa
Mar 7 08:57:05 ipx10318 kernel: printing eip:
Mar 7 08:57:05 ipx10318 kernel: 00ae78aa
Mar 7 08:57:05 ipx10318 kernel: Oops:
Mar 7 08:57:05 ipx10318 kernel: CPU:0
Mar 7 08:57:05 ipx10318 kernel: EIP:
0010:[xfs_qm_exit+11433114/-1072694288]Not tainted
Mar 7 08:57:05 ipx10318 kernel: EFLAGS: 00010246
Mar 7 08:57:05 ipx10318 kernel: eax: ebx: 00ae78aa ecx: d31a3f28
edx:
Mar 7 08:57:05 ipx10318 kernel: esi: c0116e90 edi: cf909f20 ebp:
esp: d31a3f34
Mar 7 08:57:05 ipx10318 kernel: ds: 0018 es: 0018 ss: 0018
Mar 7 08:57:05 ipx10318 kernel: Process apache (pid: 803, stackpage=d31a3000)
Mar 7 08:57:05 ipx10318 kernel: Stack: d31a2000 c0116db0 d31a3f70 c014bd3c
cf909f20
Mar 7 08:57:05 ipx10318 kernel:0246 d31a2000 0064
Mar 7 08:57:05 ipx10318 kernel:c014c0cc d31a3fa8 d31a3fa4
d31a2000 bdf8 be08
Mar 7 08:57:05 ipx10318 kernel: Call Trace:[process_timeout+0/96]
[do_select+456/516] [sys_select+812/1148] [
system_call+51/64]
Mar 7 08:57:05 ipx10318 kernel:
Mar 7 08:57:05 ipx10318 kernel: Code: Bad EIP value.
Was könnte die Ursache dafür sein?
Memtest zeigt keinen Fehler im Arbeitsspeicher
CU
Michael
--
Michael Ott, e-mail: [EMAIL PROTECTED], www.zolnott.de
I am registered as user #275453 with the Linux Counter, http://counter.li.org.
signature.asc
Description: Digital signature
Re: 'swapper' verursacht Kernel-Oops
Michelle Konzack schrieb: N'Abend, Auf meinem Elitegroup habe ich mit einem Schlag laufend Kernel-Oops Habe gerade versucht, das upstream/archives/xfree86-4.1.0.tar.gz zu entzipen, weil ich ein paar Dateien ändern muß, aber dabei bekomme ich laufend Oops'er. Der Speicher sind zwei nagelneue PC2700 von je 256 MByte und memtest86 hat nichts gefunden. Ich habe mal auch unerklärliche oops und Programmabstürze gehabt. memtest86 hatte nix gefunden. In meiner Ratlosigkeit habe ich dann trotzdem mal die Speicherriegel ausgetauscht... siehe da der Rechner lief wie am Schnürchen. Ein Riegel hatte einen Schaden den memtest86 nicht entdeckte. Meine bescheidene Empfehlung: Mal RAM-Riegel eines anderen Rechners einbauen. Grüße Alex -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
[SOLVED ?] Re: 'swapper' verursacht Kernel-Oops
Guten Morgen, habe auf dem Elitegroup Mainboard K7S7AG (SIS746) zwei nagelneue PC2700 Speicher mit je 256 MByte und nachdem ich jetzt 13 Stunden memtest86 (v2.9, direkt in der lilo.conf eingetragen) durchlaufen habe lassen, scheinen beide Module von heute auf morgen kaputt gegangen zu sein... Vieleicht ist auch das mainboard oder die Duron 1600 CPU kaputt... Werde die ganze Einheit zusammen auf http://www.ebay.de/ verklopen. Dann kommt bei mir wieder ein AsusTek A7V600-X (VIA). Am 2004-12-12 22:19:15, schrieb Michelle Konzack: N'Abend, Auf meinem Elitegroup habe ich mit einem Schlag laufend Kernel-Oops Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: 'swapper' verursacht Kernel-Oops
Am 2004-12-13 19:03:47, schrieb Christian Schmidt: Hallo Michelle, Und deshalb kannst Du natuerlich ausschliessen, dass vielleicht einer davon einen Defekt aufweist, ja? Was ist wenn das Mainboard den Hersteller nicht mag... Testen könnte man das nur, wenn man komplett andere Module nimmt. Aber abgesehen davon, es sind ja beide Module kaputt. Wie hoch ist die Warscheinlichkeit, das man 10 Module aus der gleichen Produktion kauft und das genau zwei von denen in einem rechner stechen, in dem BEIDE Module Fehler aufweisen ? Oder soll ich jetzt 3 Server runterfahren um eine Workststion zu testen ? Ich lach mich weg. HiHi Viel Spaß. Gruss, Christian Schmidt Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: 'swapper' verursacht Kernel-Oops
Hallo Alexander, Hatte lezte nacht einen zweiten memtest86 lauf gemacht, allerdings mit Version 2.9... Jetzt habe ich über 1500 Fehler... Am 2004-12-13 15:30:47, schrieb Alexander Nagel: Ich habe mal auch unerklärliche oops und Programmabstürze gehabt. memtest86 hatte nix gefunden. In meiner Ratlosigkeit habe ich dann trotzdem mal die Speicherriegel ausgetauscht... siehe da der Rechner lief wie am Schnürchen. Ein Riegel hatte einen Schaden den memtest86 nicht entdeckte. Meine bescheidene Empfehlung: Mal RAM-Riegel eines anderen Rechners einbauen. Problem:Ich habe die Speicherreigel im 10er Pack gekauft... Alles die gleichen ! Grüße Alex Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: 'swapper' verursacht Kernel-Oops
Hallo Michelle, Michelle Konzack, 13.12.2004 (d.m.y): Am 2004-12-13 15:30:47, schrieb Alexander Nagel: Meine bescheidene Empfehlung: Mal RAM-Riegel eines anderen Rechners einbauen. Problem:Ich habe die Speicherreigel im 10er Pack gekauft... Alles die gleichen ! Und deshalb kannst Du natuerlich ausschliessen, dass vielleicht einer davon einen Defekt aufweist, ja? Ich lach mich weg. Gruss, Christian Schmidt -- Friede: Die Epoche des Betrügens zwischen zwei Epochen des Kriegführens. -- Ambrose Bierce signature.asc Description: Digital signature
'swapper' verursacht Kernel-Oops
N'Abend, Auf meinem Elitegroup habe ich mit einem Schlag laufend Kernel-Oops Habe gerade versucht, das upstream/archives/xfree86-4.1.0.tar.gz zu entzipen, weil ich ein paar Dateien ändern muß, aber dabei bekomme ich laufend Oops'er. Der Speicher sind zwei nagelneue PC2700 von je 256 MByte und memtest86 hat nichts gefunden. Habe nochmal gebootet und wollte mir die tar.gz im mc ansehen dann bekomme ich einen mehrfachen Oops'er 1) kjournald 2) swapper Habe aber auch schon drei oder vier gleichzeitig gehabt... Woran kann das liegen ? Danke Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Re: 'swapper' verursacht Kernel-Oops
Michelle Konzack wrote: Habe nochmal gebootet und wollte mir die tar.gz im mc ansehen dann bekomme ich einen mehrfachen Oops'er 1) kjournald 2) swapper Habe aber auch schon drei oder vier gleichzeitig gehabt... Woran kann das liegen ? Kann vorkommen wenn irgendwo ein Sack Reis umfällt... Kernelversion, ooops Ausgabe, ... ? -- Mit freundlichen Gruessen Bjoern Schmidt -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: 'swapper' verursacht Kernel-Oops
Am 2004-12-12 22:34:04, schrieb Bjoern Schmidt: Kernelversion, ooops Ausgabe, ... ? Dumm nur das der Rechner 5 Minuten zu Fuß entfernt ist... Und die Oop'ser sind so blöd das sie nicht mehr in die Syslog geschrieben werden. Greetings Michelle -- Linux-User #280138 with the Linux Counter, http://counter.li.org/ Michelle Konzack Apt. 917 ICQ #328449886 50, rue de Soultz MSM LinuxMichi 0033/3/8845235667100 Strasbourg/France IRC #Debian (irc.icq.com) signature.pgp Description: Digital signature
Dauernd Kernel Oops, VIA Hardware Fehler?
Hallo, Mein Rechner produziert andauernd Kernel-Oopses mit einem anschließenden Absturz. Wenn er abstürtzt ist es meist der swapper Prozess oder kjournald. Hat jemand eine Idee, woran es liegen könnte? Kernel: 2.4.23 (Fehler tritt genauso bei allen anderen probierten Kernel Version seit 2.4.17 auf) VIA Apollo Chipsatz, 64MB RAM, 30GB Festplatte, AMD K6-2 350MHz. Alter Rechner umsonst von einem Freund. Bei dem lief Windows 2000 sehr stabil, daher sollte es nicht umbedingt ein Hardware Fehler sein Habe den Speicher mit memtest mehrere Durchläufe geprüft und keine Fehler festgestellt. System läuft auf ext3 Partitionen. Hier ein Beispiel Oops durch ksymoops geschickt: -- Unable to handle kernel paging request at virtual address 402ec580 c011a776 *pde = 03e39067 Oops: 0002 CPU:0 EIP:0010:[c011a776]Not tainted Using defaults from ksymoops -t elf32-i386 -a i386 EFLAGS: 00010002 eax: c011a76c ebx: c02f61b4 ecx: edx: 0046 esi: c02ec5a0 edi: fffe ebp: c02ec5a0 esp: c3f5fdd0 ds: 0018 es: 0018 ss: 0018 Process kjournald (pid: 9, stackpage=c3f5f000) Stack: 0001 c02ec5a0 fffe c011a5cb c02ec5a0 c02ea900 c3f5fe0c 0046 c010812e c3f5e000 fc18 c0292068 c3f5fe68 c010a238 c02d2000 c02ec520 c3f5e000 fc18 c3f5fe68 0001 Call Trace:[c011a5cb] [c010812e] [c010a238] [c0114406] [c01333fa] [c0163343] [c01144f6] [c0165546] [c0165420] [c010556c] Code: c7 05 80 c5 2e c0 00 00 00 00 fb 85 db 74 50 31 ff be 80 c5 EIP; c011a776 tasklet_hi_action+a/70 = eax; c011a76c tasklet_hi_action+0/70 ebx; c02f61b4 bh_task_vec+14/280 esi; c02ec5a0 softirq_vec+0/100 edi; fffe END_OF_CODE+3b751d9f/ ebp; c02ec5a0 softirq_vec+0/100 esp; c3f5fdd0 _end+3c451f4/4509424 Trace; c011a5cb do_softirq+5b/ac Trace; c010812e do_IRQ+9e/b0 Trace; c010a238 call_do_IRQ+5/d Trace; c0114406 schedule+1f2/30c Trace; c01333fa __wait_on_buffer+6e/90 Trace; c0163343 journal_commit_transaction+7b3/ec7 Trace; c01144f6 schedule+2e2/30c Trace; c0165546 kjournald+116/1c0 Trace; c0165420 commit_timeout+0/c Trace; c010556c arch_kernel_thread+28/38 Code; c011a776 tasklet_hi_action+a/70 _EIP: Code; c011a776 tasklet_hi_action+a/70 = 0: c7 05 80 c5 2e c0 00 movl $0x0,0xc02ec580 = Code; c011a77d tasklet_hi_action+11/70 7: 00 00 00 Code; c011a780 tasklet_hi_action+14/70 a: fbsti Code; c011a781 tasklet_hi_action+15/70 b: 85 db test %ebx,%ebx Code; c011a783 tasklet_hi_action+17/70 d: 74 50 je 5f _EIP+0x5f c011a7d5 tasklet_hi_action+69/70 Code; c011a785 tasklet_hi_action+19/70 f: 31 ff xor%edi,%edi Code; c011a787 tasklet_hi_action+1b/70 11: be 80 c5 00 00mov$0xc580,%esi 0Kernel panic: Aiee, killing interrupt handler! 1 warning issued. Results may not be reliable. -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Kernel-Oops nach Filesystem-Checks
Hallo,
bei ext2/3-Filesystemen ist es allgemein üblich, dass ab und an
Filesystem-Checks durchlaufen. Bei mir tut es das nach 34x booten
(Maximum mount count: 34). So weit, so gut.
Nun mein Problem:
Jedes Mal, wenn das Prozedere wieder durchläuft und fertig ist, spinnt
Alsa erst mal'ne Runde (abgeschrieben und notiert - /var/log/kern.log
hat es nicht gespeichert):
Bootvorgang:
Starting Alsa
unable to handle kernel paging request at virtual adress fa9bd3bc
printing eip:
d91a1c2f
pde =
Oops:
/etc/rc2.d/S20alsa: line 143: 358 Segmentation fault
modprobe snd-S{module}-oss /dev/null 21
Rechner steht Affengriff (Strg+Alt+Entf) Reboot
Shutting down ALSA (version 0.9.3a)
rmmod: snd-pcm-oss: Device or resource busy
rmmod: snd-mixer-oss: Device or resource busy
Rechner steht nichts geht mehr harter Reset nötig
Danach startet Debian wieder, als sei nichts geschehen.
Wo kann ich ansetzen ?
Vielen Dank
--
mmuellerss \\:// [EMAIL PROTECTED]
Mario Mueller(o -) http://forum.winner.de
Barbarastrasse 6 ---ooO-(_)-Ooo--- tel 01212 / 511568109
99752 BleicherodeSylpheed-Claws auf Debian
--
Haeufig gestellte Fragen und Antworten (FAQ):
http://www.de.debian.org/debian-user-german-FAQ/
Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED]
mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
Re: kernel-oops bei Prozessen mit pipe grossen Datenmengen
Hallo Juergen Descher, am Fri, Feb 14, 2003 at 12:03:10PM +0100 hast du folgendes geschrieben: Früher ist es schon einmal passiert das der Rechner morgens stehen geblieben ist. (anachron?) Es gab keine log-Einträge. Seid dem habe ich einen neuen kernel und die swap (3 Partitionen) vergrößert. Ob da Zusammenhänge bestehen? Wie hast du den swap Erweitert ? Eine neue Partition als swap deklariert und mit swapon aktiviert ? Steht in /proc/swaps die Partition drin ? Hast du mal deine Filesysteme (welche, ext2,ext3,reiserfs,xfs) checken lassen ? Es sieht für mich eher so aus als ob beim Zugriff auf die Platten irgendwas nicht stimmt. Oder ist ein Filesystem read only gemountet o.ä.? Gruß Thomas -- Haeufig gestellte Fragen und Antworten (FAQ): http://www.de.debian.org/debian-user-german-FAQ/ Zum AUSTRAGEN schicken Sie eine Mail an [EMAIL PROTECTED] mit dem Subject unsubscribe. Probleme? Mail an [EMAIL PROTECTED] (engl)
kernel-oops bei Prozessen mit pipe grossen Datenmengen
Hallo zusammen,
Ich habe hier ein Problem mit unkillbaren Prozessen und der pipe.
Es gibt zwei Prozesse mit dem Status D also down. Den ersten habe
ich gestern, bzw. heute ganz früh :), schon zu killen versucht. Da
selbst kill -9 nicht half. Habe ich ihm die aufrufende shell
gestohlen. Half aber auch nicht.
Nun sagt man ps:
PROCESS STATE CODES
D uninterruptible sleep (usually IO)
Hm, ist kein Zombie aber killen kann ich ihn nicht?
Jetzt kommt aber noch etwas hinzu. Der tägliche anachron hat einen
ähnliches Problem erzeugt. Dort ist find auf einmal down. Bevor
ich nun auch die Prozesse einzeln abschieße -find wird sich wohl auch
beständig wiedersetzen- wollte ich einmal fragen, ob es vielleicht
doch eine Möglichkeit gibt die Prozesse zu killen. Oder muss ein reboot
her? (Der Prozess fdupes dürfte IMHO durch die Beendigung von X, da er
in einem xterm gestartet wurde, zu erledigen sein.)
fdupes sollte ein großes Verzeichnis durchsuchen. Auch diesen Prozess
habe ich in eine Pipe geschickt:
$ fdupes -rsqn .|tee $outfile
Wobei ich tee auch schon gekillt habe, das ging. Übrigens ist im
$outfile nie ein bit angekommen.
load average ist IMHO seit/durch anachron so hoch, s.u.
Netsaint hat's verraten, ich kann leider keine Auskunft über die
vorhergehenden Werte geben.
Date/Time: Fri Feb 14 08:04:04 CET 2003
Additional Info:
load average: 2.18, 2.21, 2.02 WARNING
Früher ist es schon einmal passiert das der Rechner morgens stehen
geblieben ist. (anachron?) Es gab keine log-Einträge. Seid dem habe
ich einen neuen kernel und die swap (3 Partitionen) vergrößert. Ob da
Zusammenhänge bestehen?
Einzige Veränderung an Rechner zum Vortag (uptime 5d):
Gestern habe ich /user/local eine eigene Partition gegönnt - läuft
problemlos.
Ich habe wohl ein Problem mit der pipe. Arrgh! Jetzt sehe ich in
/var/log/kern.log Meldungen von den Zeitpunkten der ausgestiegenen
Prozese. Ich hänge sie unten an. Kann jemand damit etwas anfangen?
Wenn jemand eine mögliche Erklärung in seiner Glaskugel findet warum
die Prozesse ausgestiegen sind, wie ich sie los werde ...
Ich bin allen Erläuterungen aufgeschlossen :)
cu
Juergen
Jetzt kommen die Infos, vielleicht kann ja jemand damit etwas
anfangen:
# r! ps ax -lfj|head -1;ps ax -lfj|egrep ^[0-9]{3} D
F S PID PPID PGID SID PRI NI SZ WCHAN STIME TIME CMD
000 D 20954 1 20954 8956 69 0 809 down 00:04 0:01 fdupes
100 D 30370 30360 29371 29371 75 10 374 down 07:36 0:05 find
# r! ps -lfj -g 29371
F S PID PPID PGID SID PRI NI SZ WCHAN STIME TIME CMD
040 S 29371 1 29371 29371 69 0 350 rt_sig 07:30 00:00:00 anacron
000 S 29750 29371 29371 29371 74 10 316 select 07:35 00:00:00 run-parts
000 S 30306 29750 29371 29371 75 10 508 wait4 07:36 00:00:00 /bin/sh
000 S 30308 30306 29371 29371 75 10 314 nanosl 07:36 00:00:00 lockfile-touch
000 S 30360 30306 29371 29371 75 10 508 wait4 07:36 00:00:00 /bin/sh
100 D 30370 30360 29371 29371 75 10 374 down 07:36 00:00:05 find
000 S 30371 30360 29371 29371 75 10 584 pipe_w 07:36 00:00:00 sort
TTY ist ?
UID ist root außer bei fdupes
Cist 0
ADDR ist -
* Prozesse mit Parametern:
CMD
fdupes -rsqn .
anacron -s
run-parts --report /etc/cron.daily
/bin/sh /etc/cron.daily/standard
lockfile-touch /var/lock/cron.daily
/bin/sh /usr/sbin/checksecurity
find / /boot /var /usr /home /opt /xmnt/data \
-xdev ( -false ) -prune -o \
( -type f -perm +06000 \
-o ( ( -type b -o -type c ) -a -not ( -false ) ) \
) \
-printf %8i %5m %3n %-10u %-10g %9s %t %h/%f?n
# r! uname -a
Linux marvin 2.4.20-k6 #1 Mon Jan 13 14:22:34 EST 2003 i586 unknown
# r!free
total used free sharedbuffers cached
Mem:192652 181580 11072 0 17724 53384
-/+ buffers/cache: 110472 82180
Swap: 651148 116092 535056
* cutpast von top (BTW: geht das auch anders?) :
11:06:45 up 4 days, 2:11, 8 users, load average: 2.15, 2.12, 2.09
148 processes: 147 sleeping, 1 running, 0 zombie, 0 stopped
CPU states: 8.3% user, 5.8% system, 0.4% nice, 85.6% idle
Mem:192652K total, 183124K used, 9528K free,17804K buffers
Swap: 651148K total, 116092K used, 535056K free,53960K cached
* /var/log/kern.log
** Aufruf von fdupes
14 00:03:35 kernel: Unable to handle kernel paging request at virtual address 6c656848
14 00:03:35 kernel: printing eip:
14 00:03:35 kernel: c0142ee0
14 00:03:35 kernel: *pde =
14 00:03:35 kernel: Oops:
14 00:03:35 kernel: CPU:0
14 00:03:35 kernel: EIP:0010:[find_inode+28/72]Not tainted
14 00:03:35 kernel: EFLAGS: 00210a97
14 00:03:35 kernel: eax: ebx: 6c656820 ecx: 000e edx: cbd0
14 00:03:35 kernel: esi: 6c656820 edi: ebp: 4b7c esp: cb6f5ec4
14 00:03:35 kernel: ds: 0018 es: 0018 ss: 0018
14 00:03:35 kernel: Process fdupes (pid: 20889, stackpage=cb6f5000)
14 00:03:35 kernel
