Re: Kernel-Oops??

[Peter Kuechler]

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??

[Andreas Kroschel]

* 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??

[Paul Puschmann]

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]

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??

[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
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)

Re: Kernel-Oops??

[Peter Kuechler]

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:
> 

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??

[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:


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??

[Jochen Schulz]

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]
 


signature.asc
Description: Digital signature

Re: Kernel-Oops??

[Peter Kuechler]

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
> Pen&Paper, 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:
> > 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??

[Peter Kuechler]

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??

[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.

> 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??

[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.

> 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]

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: Kernel-Oops??

[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?

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??

[Andreas Pakulat]

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
Pen&Paper, 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)

Kernel-Oops??

[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)
Oct 17 18:01:24 pelle kernel:  [] __report_bad_irq+0x2b/0x69
Oct 17 18:01:24 pelle kernel:  [] note_interrupt+0x1c1/0x1fb
Oct 17 18:01:24 pelle kernel:  [] handle_IRQ_event+0x21/0x49
Oct 17 18:01:24 pelle kernel:  [] __do_IRQ+0xb2/0xe8
Oct 17 18:01:24 pelle kernel:  [] do_IRQ+0x43/0x51
Oct 17 18:01:24 pelle kernel:  [] common_interrupt+0x1a/0x20
Oct 17 18:01:24 pelle kernel:  [] acpi_pm_read+0x7/0xf
Oct 17 18:01:24 pelle kernel:  [] do_gettimeofday+0x2d/0xca
Oct 17 18:01:24 pelle kernel:  [] copy_to_user+0x37/0x54
Oct 17 18:01:24 pelle kernel:  [] sys_gettimeofday+0x1a/0x51
Oct 17 18:01:24 pelle kernel:  [] syscall_call+0x7/0xb
Oct 17 18:01:24 pelle kernel: handlers:
Oct 17 18:01:24 pelle kernel: [] (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

Debian stable - Samba Oops

[Stefan Bauer]

Hallo Liste,

ich betreibe hier ein Netz mit 8 Windows PC's. Win98 Win2K sowie 
WinXP. Zusätzlich natürlich ein Samba Fileserver auf Debian stable mit 
Kernel 2.6.8.x (default Kernel) in der "aktuellen" Version.


Erst gab es Probleme,dass der Samba Server nicht der lokale Master 
Browser wurde, was ich mit os level = 33 lösen konnte.


Dann hatte noch ein Client die Arbeitsgruppe rejected, was an einem 
lokalen Firewall Problem lag.


  Netbios nameserver version 3.0.14a-Debian started.
  Copyright Andrew Tridgell and the Samba Team 1994-2004
[2006/08/18 10:21:30, 0] 
nmbd/nmbd_nameregister.c:register_name_response(130)
  register_name_response: server at IP 169.254.0.8 rejected our name 
registration of ARBEITSGRUPPE<1d> IP 169.254.0.254 with error code 6.
[2006/08/18 10:21:30, 0] 
nmbd/nmbd_become_lmb.c:become_local_master_fail2(417)
  become_local_master_fail2: failed to register name 
ARBEITSGRUPPE<1d> on subnet 169.254.0.254. Failed to become a local 
master browser.



[2006/08/18 13:18:06, 0] 
nmbd/nmbd_namelistdb.c:standard_success_release(384)
  standard_success_release: Name release for name 
^A^B__MSBROWSE__^B<01> IP 169.254.0.254 on subnet 169.254.0.254. Name 
was not found on subnet.
[2006/08/18 13:18:06, 0] 
nmbd/nmbd_namelistdb.c:standard_fail_register(283)
  standard_fail_register: Failed to register/refresh name 
ARBEITSGRUPPE<1d> on subnet 169.254.0.254

[2006/08/18 13:18:06, 0] lib/fault.c:fault_report(36)
  ===
[2006/08/18 13:18:06, 0] lib/fault.c:fault_report(37)
  INTERNAL ERROR: Signal 11 in pid 1888 (3.0.14a-Debian)
  Please read the appendix Bugs of the Samba HOWTO collection
[2006/08/18 13:18:06, 0] lib/fault.c:fault_report(39)
  ===
[2006/08/18 13:18:06, 0] lib/util.c:smb_panic2(1485)
 smb_panic(): calling panic action [/usr/share/samba/panic-action 1888]
[2006/08/18 13:18:26, 0] lib/util.c:smb_panic2(1493)
  smb_panic(): action returned status 0
[2006/08/18 13:18:26, 0] lib/util.c:smb_panic2(1495)
  PANIC: internal error
[2006/08/18 13:18:26, 0] lib/util.c:smb_panic2(1503)
  BACKTRACE: 14 stack frames:
   #0 /usr/sbin/nmbd(smb_panic2+0x111) [0x80cd781]
   #1 /usr/sbin/nmbd(smb_panic+0x1a) [0x80cd66a]
   #2 /usr/sbin/nmbd [0x80baaa8]
   #3 [0xe420]
   #4 /usr/sbin/nmbd(retransmit_or_expire_response_records+0x127) 
[0x8070d27]

   #5 /usr/sbin/nmbd(unbecome_local_master_browser+0x160) [0x8063770]
   #6 /usr/sbin/nmbd [0x8063ae6]
   #7 /usr/sbin/nmbd [0x806c08a]
   #8 /usr/sbin/nmbd [0x8070b64]
   #9 /usr/sbin/nmbd(run_packet_queue+0x7f) [0x8070bef]
   #10 /usr/sbin/nmbd [0x80619aa]
   #11 /usr/sbin/nmbd(main+0x3ea) [0x806203a]
   #12 /lib/tls/libc.so.6(__libc_start_main+0xf4) [0x4016f974]
   #13 /usr/sbin/nmbd [0x8060811]


Komischerweise gab ohne die oben genannten Änderungen einen Panic.

Nach den oben vorgenommenen Änderungen läuft er jetzt seit 18.08.

Nun stelle ich mir die Frage ob etwa Samba zu alt ist oder wodurch der 
oben angegebene Panic entstanden ist, ob er evtl. erneut passiert und 
meine Änderungen garnichts damit zu tun hatten?


Für jegliche Idee dankbar.

-

Mit freundlichen Grüßen

Stefan Bauer

-->
www.plzk.de - www.plzk.com
---<


--
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: Oops

[Florian Ludwig]

Christoph Marcel Hilberg wrote:

>Hallo Leute, 
>
>  
>
Moin

>Habe so einen "Super Multi DVD Rewriter" external von LG erstanden. Das
>Model heist, GSA-5163D 
>Erkennen, mounten, lesen geht alles. Nach dem Ausstecken (Gerät war noch
>an) passiert ein Oops. 
>

Nach dem Ausstecken - und auch nach dem umount?

Florian Ludwig


-- 
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)

Oops

[Christoph Marcel Hilberg]

Hallo Leute, 

Habe so einen "Super Multi DVD Rewriter" external von LG erstanden. Das
Model heist, GSA-5163D 
Erkennen, mounten, lesen geht alles. Nach dem Ausstecken (Gerät war noch
an) passiert ein Oops. Und weil es so schön ist habe ich den Ausschnitt
aus der syslog gleich mit hier dabei gelegt. Nach einem Hard Reset läßt
sich der Fehler reproduzieren. 
Kann damit jemand was anfangen? 

c-toph

-- 
best regards Schoene Gruesse Christoph Marcel Hilberg
Oct 23 20:18:38 ruach kernel: usb 3-2.4: new high speed USB device using 
address 4
Oct 23 20:18:39 ruach kernel: Initializing USB Mass Storage driver...
Oct 23 20:18:39 ruach kernel: scsi1 : SCSI emulation for USB Mass Storage 
devices
Oct 23 20:18:39 ruach kernel:   Vendor: HL-DT-ST  Model: DVDRAM GSA-5163D  Rev: 
A102
Oct 23 20:18:39 ruach kernel:   Type:   CD-ROM ANSI 
SCSI revision: 02
Oct 23 20:18:39 ruach kernel: sr0: scsi3-mmc drive: 40x/40x writer dvd-ram 
cd/rw xa/form2 cdda tray
Oct 23 20:18:39 ruach kernel: Attached scsi CD-ROM sr0 at scsi1, channel 0, id 
0, lun 0
Oct 23 20:18:39 ruach scsi.agent[4466]:  sr_mod: loaded sucessfully (for 
cdrom)
Oct 23 20:18:39 ruach kernel: USB Mass Storage device found at 4
Oct 23 20:18:39 ruach kernel: usbcore: registered new driver usb-storage
Oct 23 20:18:39 ruach kernel: USB Mass Storage support registered.
Oct 23 20:18:39 ruach usb.agent[4428]:  usb-storage: loaded successfully
Oct 23 20:18:39 ruach scsi.agent[4466]:  sg: loaded sucessfully (for cdrom)
Oct 23 20:18:39 ruach kernel: Attached scsi generic sg0 at scsi1, channel 0, id 
0, lun 0,  type 5
Oct 23 20:21:01 ruach ntpd[3525]: synchronized to LOCAL(0), stratum 10
Oct 23 20:21:01 ruach ntpd[3525]: kernel time sync disabled 0041
Oct 23 20:21:30 ruach kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Oct 23 20:21:30 ruach kernel: ISO 9660 Extensions: RRIP_1991A
Oct 23 20:22:06 ruach ntpd[3525]: synchronized to 192.168.1.2, stratum 3
Oct 23 20:23:42 ruach kernel: ISO 9660 Extensions: Microsoft Joliet Level 3
Oct 23 20:23:42 ruach kernel: ISO 9660 Extensions: RRIP_1991A
Oct 23 20:24:32 ruach kernel: usb 3-2.4: USB disconnect, address 4
Oct 23 20:24:37 ruach kernel: scsi: Device offlined - not ready after error 
recovery: host 1 channel 0 id 0 lun 0
Oct 23 20:24:37 ruach kernel: sr 1:0:0:0: Illegal state transition 
cancel->offline
Oct 23 20:24:37 ruach kernel: Badness in scsi_device_set_state at 
drivers/scsi/scsi_lib.c:1643
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+830328/859569] 
scsi_device_set_state+0xc6/0x120 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+820422/859569] 
scsi_eh_offline_sdevs+0x64/0x80 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+821998/859569] 
scsi_unjam_host+0xcc/0x200 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [default_wake_function+0/32] 
default_wake_function+0x0/0x20
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+822565/859569] 
scsi_error_handler+0x103/0x1c0 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+822306/859569] 
scsi_error_handler+0x0/0x1c0 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [kernel_thread_helper+5/20] 
kernel_thread_helper+0x5/0x14
Oct 23 20:24:37 ruach kernel: Badness in kobject_get at lib/kobject.c:433
Oct 23 20:24:37 ruach kernel:  [kobject_get+76/80] kobject_get+0x4c/0x50
Oct 23 20:24:37 ruach kernel:  [get_device+24/48] get_device+0x18/0x30
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+828103/859569] 
scsi_request_fn+0x25/0x400 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [blk_insert_request+186/224] 
blk_insert_request+0xba/0xe0
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+823547/859569] 
scsi_queue_insert+0x89/0xd0 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+821667/859569] 
scsi_eh_flush_done_q+0x71/0xf0 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+821946/859569] 
scsi_unjam_host+0x98/0x200 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [default_wake_function+0/32] 
default_wake_function+0x0/0x20
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+822565/859569] 
scsi_error_handler+0x103/0x1c0 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [__crc_register_netdevice+822306/859569] 
scsi_error_handler+0x0/0x1c0 [scsi_mod]
Oct 23 20:24:37 ruach kernel:  [kernel_thread_helper+5/20] 
kernel_thread_helper+0x5/0x14
Oct 23 20:24:37 ruach kernel: Unable to handle kernel paging request at virtual 
address 00100104
Oct 23 20:24:37 ruach kernel:  printing eip:
Oct 23 20:24:37 ruach kernel: f890aa70
Oct 23 20:24:37 ruach kernel: *pde = 
Oct 23 20:24:37 ruach kernel: Oops: 0002 [#1]
Oct 23 20:24:37 ruach kernel: PREEMPT 
Oct 23 20:24:37 ruach kernel: Modules linked in: nls_cp850 isofs sg usb_storage 
md5 ipv6 nbd thermal fan button processor ehci_hcd tsdev mousedev joydev evdev 
usbhid eth1394 ohci_hcd usbcore ohci1394 ieee1394 3c59x aic7xxx snd_cmipci 
snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc

[SOLVED] OOPs bei kswapd

[Gerhard Brauer]

Gruesse!
* Gerhard Brauer <[EMAIL PROTECTED]> schrieb am [18.07.05 17:07]:
> * Richard Mittendorfer <[EMAIL PROTECTED]> schrieb am [18.07.05 16:11]:
 
> > ich glaube kaum, dass es sich um einen plattenfehler handelt, aber SMART
> > koennte da sicherheit geben. mir waer aber kein zusammenhang bekannt.
> > (smartctl, smartmon-tools)
> 
> Ich eigentlich auch nicht (außer sagen wir in dem Sektoren-Bereich wo
> außgerechnet die Swap-Partition liegt). Mit sowas gehen aber meiner
> Erfahrung nach read/write Errormeldungen im syslog einher (außer evtl.
> halt beim swap fs ?). Smart ist mit dieser Festplatte und mit diesem PC
> soweit ich weiß noch nicht möglich.

So, Problem gelöst. Ich poste es hier noch, um anderen eine
wahrscheinliche Ursache für das Problem anzubieten.

Es war die Festplatte. Und zwar waren genau und ausschließlich in der
Swap-Partition defekte Blöcke vorhanden.

Das im syslog keine Fehlermeldungen kamen ist IMHO dadurch bedingt, das
swap kein FS im eigentlichen Sinn ist und auch nicht vom Kernel
behandelt wird wie andere FSe. Sondern eben auschließlich über den
kswapd.

Rechner und RAM wurden mehrere Stunden durch gleichzeitiges cpuburn,
memcheck im laufenden System und ein find-grep über die / gestresst,
ohne das Fehler auftraten.

Erst ein badblocks -vw /dev/hda fand die schlechten
Blöcke, ein badblocks im read bzw. non-destruktiv-write nicht.

Alternativ wurden die defekten Blöcke auch bei einem:
mkswap -c /dev/hda
gefunden.

Gruß Gerhard

-- 
Linux ist wenn es trotzdem geht...

Re: OOPs bei kswapd

[Richard Mittendorfer]

Also sprach Gerhard Brauer <[EMAIL PROTECTED]> (Mon, 18 Jul 2005
17:07:39 +0200):
> Gruesse!

hoi!

> * Richard Mittendorfer <[EMAIL PROTECTED]> schrieb am [18.07.05 16:11]:
> > Also sprach Gerhard Brauer <[EMAIL PROTECTED]> (Mon, 18 Jul 2005
> > 14:37:43 +0200):
> 
> > > Gruesse!
> > > 
> > > Kann mir jemand einen Tip geben, warum bei einem Rechner der
> > > kswapd Daemon im laufenden Betrieb stirbt?
> > > 
> > > Ich kriege einen Kernel-OOPs ins syslog, der kswapd steht danach
> > > als defunct in der Prozeßliste. Der Rechner läuft anschließend
> > > "relativ" normal weiter (außer sendmail/exim)
> > > [...]
> > 
> > ist's immer der kswapd? 
> 
> Ja, immer der kswapd. *Nach* dem oops haben dann clamav und exim
> Probleme. clamav kann auf seinen socket nicht mehr zugreifen und exim
> versendet keine Mails mehr. Ich habe es als Folgeprobleme eingestuft
> da der Rechner scheinbar ja kein paging (sowohl in wie out) mehr
> machen kann.

mit sicherheit. nach nem oops (wenn's ueberhaupt noch geht) restarten -
danach kannst dich auf nichts mehr verlassen.

> Der PC ist ein alter K6 266 mit 96 MB RAM (EDO), der als
> Router,Firwall und Mail/IMAP-Server dient.

sowas hatte ich vor kurzem noch in einsatz. war ein p166 mit 2 mal 2 32M
riegeln, wovon einer von 16M - 20M defekte bereiche hatte. nach einem
memtest hab ich die schlechten flecken im ram mit dem badmem-patch
(gibt's fuer 2.4.xx / 2.6 weiss nicht) ausgeschlossen. grosszuegig
ausgeschlossen, dann war's ok.

> Ursprünglich dachte ich beim Betrieb des Rechners, er hätte ein
> diffuses Problem. Ich kontrolliere diesen PC ausschließlich über ssh
> bzw. aufgrund von Meldungen von logcheck. Und laut Anwendet vor Ort
> gingen immer mal wieder "Internet" nicht, "Netzwerk geht nicht", etc.
> Zu diesem Zeitpunkt habe ich den Rechner mal schonmal eine Zeit mit
> Stresstest überzogen und letztendlich den Software-Watchdog aktiviert
> und konfiguriert. Die Ursache des Ganzen entpuppte sich aber später
> als ein kaputter Switch im LAN ("Scheißproblem": vergaß zeitweise die
> MAC-Adressen bzw. der Switch-Speicher defekt).

das sind _echt_ laesstige (und schwer auszumachende) !#%$probleme.

> Dies nur als Hinweis, das der Rechner eigentlich stabil ist, bis auf
> das kswapd Problem, was vor ca. 4-5 Wochen das erstemal aufgetaucht
> ist. Der Zeitpunkt könnte latürnich auf einen beginnenden
> Hardware-Defekt deuten.

das tritt recht sporatisch auf - davon kann ich ein lied singen. nachdem
er ja bis vor einiger zeit brav gelaufen ist, vermute ich was auf der
hardwareseite. also wenn du mal vorort bist, alle kontakte checken* und
nen' memtest laufen lassen. vielleicht hast du ja andere alte hardware
zum ersetzten der kiste. das klappt im allgemeinen fein: platten ins
neue teil und (fast) fertig.

es gibt auch ein memtest fuer den laufenden betrieb. den hab ich aber
noch nicht getestet - ist vermutlich nichts anderes wie ein cpuburn
(oder wie der stresstest heisst) plus der (versuchten) identifizierung
der defekten bits.

* neu einbauen, davor reinigen, nach korrosierten stellen suchen - nicht
lachen! das ist bei so alten dingern alles andere als unmoeglich ;)

> > wie sieht's mit nfs-last, find in / oder
> > kernelbauen aus? das wuerde dann eher auf ein kaputtes rammodul
> > hinweisen - mal (lange) mit memtest86 testen.
> 
> RAM könnte sein. Intensiv testen (find, etc) kann ich erst heute
> nacht, memtest erst wenn ich mal wieder vor Ort bin. Allerdings habe
> ich keine Effekte (kaputte Dateien/Filesystem), die ansonst noch auf
> einen RAM-Defekt hindeuten würden.

ich wuerd's nicht beschwoeren, aber das hoert sich nach kaputten
speicher an. wenn's nun nur ein kleiner bereich ist, der vielleicht
sogar nur bestimmte bits falsch "speichert", dann wird eventuell auch
einige intensive find's u.ae. u.U. nichts zeigen. ich wuerd' einen
memtest86 ueber nacht (ueber tage) laufen lassen - damit bist du auf der
sicheren seite.

> > ich glaube kaum, dass es sich um einen plattenfehler handelt, aber
> > SMART koennte da sicherheit geben. mir waer aber kein zusammenhang
> > bekannt. (smartctl, smartmon-tools)
> 
> Ich eigentlich auch nicht (außer sagen wir in dem Sektoren-Bereich wo
> außgerechnet die Swap-Partition liegt). Mit sowas gehen aber meiner
> Erfahrung nach read/write Errormeldungen im syslog einher (außer evtl.
> halt beim swap fs ?). Smart ist mit dieser Festplatte und mit diesem
> PC soweit ich weiß noch nicht möglich.

mit 96M wirst du die swap nicht ausschalten koennen, und ich seh' das
auch so: eine fehlerhafte platte wuerde noch andere meldungen im log
bringen. wenn dein kernel "swapfiles" kann, ko

Re: OOPs bei kswapd

[Gerhard Brauer]

Gruesse!

Ach shit, Nachtrag:

der angehängte oops.txt ist eine Meldung vom logcheck. Der oops passiert
natürlich *nicht* dreimal hintereinander, sondern logcheck wertet ja
mehrere logs aus, in denen der oops aufschlug. Sorry.

Auch ist mir jetzt noch aufgefallen, das der oops kurz/während des
morgendlichen cron-Laufs passiert ist. Ich muß den Zeitpunkt der anderen
OOPse nochmal kontrollieren, wenn die aber auch gegen 6:25 passiert sind
könnte das doch verstärkt auf RAM hinweisen.

> Den oops hänge ich als Text an. Ich habe den oops mal hier lokal an
> ksymoops verfüttert, aber richtig sinnvoll ist das doch nur, wenn ich es
> auf dem betroffenen Rechner mache? 

Gruß Gerhard

-- 
Ist Ihnen mutt zu kompliziert? Ihr Mailprogramm zu "fett"?
Sie moegen keine man pages?
Versuchen Sie: rm -rf (ReadMail -Realy Fast)

Re: OOPs bei kswapd

[Gerhard Brauer]

Gruesse!
* Richard Mittendorfer <[EMAIL PROTECTED]> schrieb am [18.07.05 16:11]:
> Also sprach Gerhard Brauer <[EMAIL PROTECTED]> (Mon, 18 Jul 2005
> 14:37:43 +0200):

> > Gruesse!
> > 
> > Kann mir jemand einen Tip geben, warum bei einem Rechner der kswapd
> > Daemon im laufenden Betrieb stirbt?
> > 
> > Ich kriege einen Kernel-OOPs ins syslog, der kswapd steht danach als
> > defunct in der Prozeßliste. Der Rechner läuft anschließend "relativ"
> > normal weiter (außer sendmail/exim)
> > [...]
> 
> ist's immer der kswapd? 

Ja, immer der kswapd. *Nach* dem oops haben dann clamav und exim
Probleme. clamav kann auf seinen socket nicht mehr zugreifen und exim
versendet keine Mails mehr. Ich habe es als Folgeprobleme eingestuft da
der Rechner scheinbar ja kein paging (sowohl in wie out) mehr machen
kann.

Der PC ist ein alter K6 266 mit 96 MB RAM (EDO), der als Router,Firwall
und Mail/IMAP-Server dient.

Ursprünglich dachte ich beim Betrieb des Rechners, er hätte ein diffuses
Problem. Ich kontrolliere diesen PC ausschließlich über ssh bzw.
aufgrund von Meldungen von logcheck. Und laut Anwendet vor Ort gingen
immer mal wieder "Internet" nicht, "Netzwerk geht nicht", etc.
Zu diesem Zeitpunkt habe ich den Rechner mal schonmal eine Zeit mit
Stresstest überzogen und letztendlich den Software-Watchdog aktiviert
und konfiguriert. Die Ursache des Ganzen entpuppte sich aber später als
ein kaputter Switch im LAN ("Scheißproblem": vergaß zeitweise die
MAC-Adressen bzw. der Switch-Speicher defekt).

Dies nur als Hinweis, das der Rechner eigentlich stabil ist, bis auf das
kswapd Problem, was vor ca. 4-5 Wochen das erstemal aufgetaucht ist. Der
Zeitpunkt könnte latürnich auf einen beginnenden Hardware-Defekt deuten.

> wie sieht's mit nfs-last, find in / oder
> kernelbauen aus? das wuerde dann eher auf ein kaputtes rammodul
> hinweisen - mal (lange) mit memtest86 testen.

RAM könnte sein. Intensiv testen (find, etc) kann ich erst heute nacht,
memtest erst wenn ich mal wieder vor Ort bin. Allerdings habe ich keine
Effekte (kaputte Dateien/Filesystem), die ansonst noch auf einen
RAM-Defekt hindeuten würden.

> ich glaube kaum, dass es sich um einen plattenfehler handelt, aber SMART
> koennte da sicherheit geben. mir waer aber kein zusammenhang bekannt.
> (smartctl, smartmon-tools)

Ich eigentlich auch nicht (außer sagen wir in dem Sektoren-Bereich wo
außgerechnet die Swap-Partition liegt). Mit sowas gehen aber meiner
Erfahrung nach read/write Errormeldungen im syslog einher (außer evtl.
halt beim swap fs ?). Smart ist mit dieser Festplatte und mit diesem PC
soweit ich weiß noch nicht möglich.

> kernel-version bekommst du mit "$ uname -r", wenn die sehr out-of-date
> ist, dann updaten (eventuell aber bei der 2.X-version bleiben, da sonst
> noch anderes noetig sein wird: modules-init-tools,..). hier gilt aber
> selbiges: sehe keinen zusammenhang mit deinem oops.

Ist ein 2.4.27 oder 2.4.29. Mit xx?? wollte ich sagen, ich kann ohne auf
den Rechner zu gehen momentan die genaue Minor-Version nicht sagen. Aber
sooo out-of-date ist er sicher nicht.  Ah, ist der
letzte stavile 2.4er von backports.org.

> poste mal die fehlermeldung aus messages, schau dir ksymoops an.

Den oops hänge ich als Text an. Ich habe den oops mal hier lokal an
ksymoops verfüttert, aber richtig sinnvoll ist das doch nur, wenn ich es
auf dem betroffenen Rechner mache? 

> sl ritch

Gruß Gerhard

-- 
Try rm -rf (_R_ead _M_ail _R_ealy _F_ast)
Jul 18 06:26:22 bastille kernel: Unable to handle kernel paging request at 
virtual address 00020014
Jul 18 06:26:22 bastille kernel:  printing eip:
Jul 18 06:26:22 bastille kernel: c0146e8e
Jul 18 06:26:22 bastille kernel: *pde = 
Jul 18 06:26:22 bastille kernel: Oops: 
Jul 18 06:26:22 bastille kernel: CPU:0
Jul 18 06:26:22 bastille kernel: EIP:0010:[prune_dcache+206/344]Not 
tainted
Jul 18 06:26:22 bastille kernel: EFLAGS: 00010206
Jul 18 06:26:22 bastille kernel: eax: 0002   ebx: c002a178   ecx: c0eccd70  
 edx: c0eccd70
Jul 18 06:26:22 bastille kernel: esi: c002a160   edi: c0eccd60   ebp: 030b  
 esp: c10c5f6c
Jul 18 06:26:22 bastille kernel: ds: 0018   es: 0018   ss: 0018
Jul 18 06:26:22 bastille kernel: Process kswapd (pid: 4, stackpage=c10c5000)
Jul 18 06:26:22 bastille kernel: Stack: 003c 01d0 001b c02453bc 
c014719b 04da c012e92c 0006 
Jul 18 06:26:22 bastille kernel:01d0 c02453bc 0001 c10c4000 
 0007 c10c5fa8  
Jul 18 06:26:22 bastille kernel:c012eaaa c02452e0  c10c4249 
0008e000 c012eb16 c02452e0 c10c4000 
Jul 18 06:26:22 bastille kernel: Call Trace:[shrink_dcache_memory+27/52] 
[try_to_free_pages_zone+120/232] [kswapd_balance_pgdat+86/164] 
[kswapd_balance+30/52] [kswapd+153/180]
Jul 18 06:26:22 bastille kernel:   [arch_kernel_thread

Re: OOPs bei kswapd

[Richard Mittendorfer]

Also sprach Gerhard Brauer <[EMAIL PROTECTED]> (Mon, 18 Jul 2005
14:37:43 +0200):
> Gruesse!
> 
> Kann mir jemand einen Tip geben, warum bei einem Rechner der kswapd
> Daemon im laufenden Betrieb stirbt?
> 
> Ich kriege einen Kernel-OOPs ins syslog, der kswapd steht danach als
> defunct in der Prozeßliste. Der Rechner läuft anschließend "relativ"
> normal weiter (außer sendmail/exim)
> [...]

ist's immer der kswapd? wie sieht's mit nfs-last, find in / oder
kernelbauen aus? das wuerde dann eher auf ein kaputtes rammodul
hinweisen - mal (lange) mit memtest86 testen.

ich glaube kaum, dass es sich um einen plattenfehler handelt, aber SMART
koennte da sicherheit geben. mir waer aber kein zusammenhang bekannt.
(smartctl, smartmon-tools)

kernel-version bekommst du mit "$ uname -r", wenn die sehr out-of-date
ist, dann updaten (eventuell aber bei der 2.X-version bleiben, da sonst
noch anderes noetig sein wird: modules-init-tools,..). hier gilt aber
selbiges: sehe keinen zusammenhang mit deinem oops.

poste mal die fehlermeldung aus messages, schau dir ksymoops an.

sl ritch

OOPs bei kswapd

[Gerhard Brauer]

Gruesse!

Kann mir jemand einen Tip geben, warum bei einem Rechner der kswapd
Daemon im laufenden Betrieb stirbt?

Ich kriege einen Kernel-OOPs ins syslog, der kswapd steht danach als
defunct in der Prozeßliste. Der Rechner läuft anschließend "relativ"
normal weiter (außer sendmail/exim)

Aber um einen Reboot komme ich da ja nicht herum.

Swap-Space ist genügend vorhanden und wird eh kaum genutzt. Die Load ist
absolut normal.

Googlen war nicht sehr erhellend. 

Ich vermute ein Kernel-Problem (2.4.XX???) oder ein Festplatten-Problem.
Aber gegen dein Platten-Problem spricht "eigentlich" das Swap und / auf
der gleichen Platte sind und der Rechner einzig nur beim kswapd zickt.

Hat jemand noch einen heißen Tip?
Ansonsten steht bei dem Rechner sowieso demnächst ein Update auf Sarge
an, dann wird auch ein neuer Kernel installiert.

Gruß Gerhard

-- 
MSCI = M$cro Soft Certificated Installer

Re: Grund für Kernel Oops

[Michelle Konzack]

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-

und vor allem das notwendige Hintergrundwissen. Du
kannst dann die Calls in den kernel-source-
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

[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:  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]

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

[Christian Schmidt]

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

Re: 'swapper' verursacht Kernel-Oops

[Michelle Konzack]

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

[SOLVED ?] Re: 'swapper' verursacht Kernel-Oops

[Michelle Konzack]

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

[Alexander Nagel]

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)

Re: 'swapper' verursacht Kernel-Oops

[Michelle Konzack]

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

Re: 'swapper' verursacht Kernel-Oops

[Bjoern Schmidt]

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)

'swapper' verursacht Kernel-Oops

[Michelle Konzack]

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: kde 3.2 unstable sourcen - Oops!!

[Bernhard Kainz]

Andreas Pakulat wrote:
On 20.Feb 2004 - 15:35:30, Peter Kuechler wrote:

Am Freitag, 20. Februar 2004 01:32 schrieb Andreas Pakulat:

On 19.Feb 2004 - 23:51:19, starstyle wrote:

hallo,

gibts irgendwo schon apt-sourcen für kde3.2 für debian sid (unstable)?
Sollte mir hier ein Irrtum unterlaufen sein?
Eben sehe ich, das hier von _Sourcen_ gesprochen wurde. Ich habe allerdings 
fertige Binarys installiert, also nicht selbst übersetzt!

Ich hoffe ich habe durch diese falsche Info keinen Schaden angerichtet...


Source (engl) = Quelle (dt.)

Derjenige wollte wissen ob es jmd gibt der KDE3.2 Pakete fuer sid
bereitstellt. Also ob es eine Apt-Quelle fuer KDE3.2 fuer sid gibt.
Andreas

bin a bisserl spät dran heut - zu lange in der arbeit gewesen. danke 
genau das wollt ich haben.

Bernhard

--
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: kde 3.2 unstable sourcen - Oops!!

[Peter Kuechler]

Am Freitag, 20. Februar 2004 17:38 schrieb Andreas Pakulat:
> On 20.Feb 2004 - 15:35:30, Peter Kuechler wrote:
> > Am Freitag, 20. Februar 2004 01:32 schrieb Andreas Pakulat:
> > > On 19.Feb 2004 - 23:51:19, starstyle wrote:
> > > > hallo,
> > > >
> > > > gibts irgendwo schon apt-sourcen für kde3.2 für debian sid
> > > > (unstable)?
> >
> > Sollte mir hier ein Irrtum unterlaufen sein?
> > Eben sehe ich, das hier von _Sourcen_ gesprochen wurde. Ich habe
> > allerdings fertige Binarys installiert, also nicht selbst übersetzt!
> >
> > Ich hoffe ich habe durch diese falsche Info keinen Schaden angerichtet...
>
> Source (engl) = Quelle (dt.)
>
> Derjenige wollte wissen ob es jmd gibt der KDE3.2 Pakete fuer sid
> bereitstellt. Also ob es eine Apt-Quelle fuer KDE3.2 fuer sid gibt.

Na dann ist es ja gut
Stimmt, wenn Du es so sagst...;-)

-- 

mfg

Peter Küchler 


--
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: kde 3.2 unstable sourcen - Oops!!

[Andreas Pakulat]

On 20.Feb 2004 - 15:35:30, Peter Kuechler wrote:
> Am Freitag, 20. Februar 2004 01:32 schrieb Andreas Pakulat:
> > On 19.Feb 2004 - 23:51:19, starstyle wrote:
> > > hallo,
> > >
> > > gibts irgendwo schon apt-sourcen für kde3.2 für debian sid (unstable)?
> 
> Sollte mir hier ein Irrtum unterlaufen sein?
> Eben sehe ich, das hier von _Sourcen_ gesprochen wurde. Ich habe allerdings 
> fertige Binarys installiert, also nicht selbst übersetzt!
> 
> Ich hoffe ich habe durch diese falsche Info keinen Schaden angerichtet...

Source (engl) = Quelle (dt.)

Derjenige wollte wissen ob es jmd gibt der KDE3.2 Pakete fuer sid
bereitstellt. Also ob es eine Apt-Quelle fuer KDE3.2 fuer sid gibt.

Andreas

-- 
If you keep your mind sufficiently open, people will throw a lot of
rubbish into it.
-- William Orton


-- 
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: kde 3.2 unstable sourcen - Oops!!

[Peter Kuechler]

Am Freitag, 20. Februar 2004 01:32 schrieb Andreas Pakulat:
> On 19.Feb 2004 - 23:51:19, starstyle wrote:
> > hallo,
> >
> > gibts irgendwo schon apt-sourcen für kde3.2 für debian sid (unstable)?

Sollte mir hier ein Irrtum unterlaufen sein?
Eben sehe ich, das hier von _Sourcen_ gesprochen wurde. Ich habe allerdings 
fertige Binarys installiert, also nicht selbst übersetzt!

Ich hoffe ich habe durch diese falsche Info keinen Schaden angerichtet...

-- 

mfg

Peter Küchler 


--
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)

Fehlermeldung Oops

[Stefan Bachem]

Hallo Alle

Eben viel mir ein Problem mit meinem Arbeits Rechner auf, 
der Kernel Produziert wenn ich das Programm bplay 
zum Abspielen von Musikdateien nutze die unten Angehaengte
Oops Fehlermeldung. Der Fehler trat heute zum ersten Mal auf und
ist Reproduzierbar.
Es handelt sich um eine Debian Woody Installation mit einem 2.4.20
Kernel auf einem in Ehren ergrauten Pentium1-233 der bisher nie 
Aerger gemacht.

Normalerweise wuerde ich es bei einem Reboot der Kiste belassen,
uptime ist zurzeit 60 Tage, da kann normale Hardware schonmal Madig 
werden.
Nun ist es aber nicht alzulange her das mal von einem Exploit die
Rede war das sich durch solche Oops Fehlermeldungen bemerkbar macht.

Der Rechner ist nur indirekt ueber einen fli4l mit dem Internet
Verbunden Telnet ist abgeschaltet und eingehendes ssh ist nicht richtig 
konfiguriert. (Er war aus dem Internen Netz nie ereichbar) 

Was meint ihr, ist das was Ernstes?

ciao
Stefan:wq

 

Feb  3 21:23:41 darkstar kernel:  <1>Unable to handle kernel NULL
pointer dereference at virtual address 0404
Feb  3 21:23:41 darkstar kernel:  printing eip:
Feb  3 21:23:41 darkstar kernel: c01142a8
Feb  3 21:23:41 darkstar kernel: Oops: 0002
Feb  3 21:23:41 darkstar kernel: CPU:0
Feb  3 21:23:41 darkstar kernel: EIP:0010:[complete+16/196]Not
tainted
Feb  3 21:23:41 darkstar kernel: EFLAGS: 00010086
Feb  3 21:23:41 darkstar kernel: eax: 0400   ebx: c639d980   ecx:
c6ef20e4
 edx: c6ef2000
 Feb  3 21:23:41 darkstar kernel: esi: 40130344   edi: 0400   ebp:
 c6ef3f9c
  esp: c6ef3f84
  Feb  3 21:23:41 darkstar kernel: ds: 0018   es: 0018   ss: 0018
  Feb  3 21:23:41 darkstar kernel: Process bplay (pid: 31850,
  stackpage=c6ef3000)
  Feb  3 21:23:41 darkstar kernel: Stack: c639d980 40130344 c6ef2000
  14878003 0246 0286 ff00 c0115698
  Feb  3 21:23:41 darkstar kernel:c0119ffb c6ef2000 40130344
   ba48 c011a29f ff00 c0106f83
  Feb  3 21:23:41 darkstar kernel: 080480f4 40131e48
  40130344  ba48 0001 002b
  Feb  3 21:23:41 darkstar kernel: Call Trace:[mm_release+32/36]
  [do_exit+107/744] [sys_exit+15/16] [system_call+51/64]
  Feb  3 21:23:41 darkstar kernel:
  Feb  3 21:23:41 darkstar kernel: Code: f0 fe 4f 04 0f 88 51 0e 00 00
  ff 07 8d 47 04 89 45 f8 c7 45
  



-- 
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)

Dauernd Kernel Oops, VIA Hardware Fehler?

[Philipp]

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:[]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:[] [] [] [] 
[]
 [] [] [] [] []
Code: c7 05 80 c5 2e c0 00 00 00 00 fb 85 db 74 50 31 ff be 80 c5

>>EIP; c011a776<=

>>eax; c011a76c 
>>ebx; c02f61b4 
>>esi; c02ec5a0 
>>edi; fffe 
>>ebp; c02ec5a0 
>>esp; c3f5fdd0 <_end+3c451f4/4509424>
Trace; c011a5cb 
Trace; c010812e 
Trace; c010a238 
Trace; c0114406 
Trace; c01333fa <__wait_on_buffer+6e/90>
Trace; c0163343 
Trace; c01144f6 
Trace; c0165546 
Trace; c0165420 
Trace; c010556c 
Code;  c011a776 
 <_EIP>:
Code;  c011a776<=
  0:   c7 05 80 c5 2e c0 00  movl   $0x0,0xc02ec580   <=
Code;  c011a77d 
  7:   00 00 00
Code;  c011a780 
  a:   fbsti
Code;  c011a781 
  b:   85 db test   %ebx,%ebx
Code;  c011a783 
  d:   74 50 je 5f <_EIP+0x5f> c011a7d5 

Code;  c011a785 
  f:   31 ff xor%edi,%edi
Code;  c011a787 
 11:   be 80 c5 00 00mov$0xc580,%esi

<0>Kernel 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

[Mario Mueller]

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 2>&1

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

[Thomas Reiß]

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

[Juergen Descher]

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


* cut&past 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: 00