Kein Betreff

>From guckes  Mon Dec 21 20:39:17 1998
Return-Path: <owner-linux-l at calle.in-berlin.de>
Delivered-To: guckes at math.fu-berlin.de
Received: (qmail 18895 invoked from network); 21 Dec 1998 19:39:16 -0000
Received: from methan.in-berlin.de (160.45.10.13)
  by leibniz.math.fu-berlin.de with SMTP; 21 Dec 1998 19:39:16 -0000
Received: from calle.in-berlin.de (root at calle.in-berlin.de [193.175.21.97])
	by methan.in-berlin.de (8.9.1/8.9.1) with ESMTP id UAA29989;
	Mon, 21 Dec 1998 20:39:01 +0100 (CET)
	(envelope-from owner-linux-l at calle.in-berlin.de)
Received: by calle.in-berlin.de (Smail3.2.0.98) 
	  from  localhost with smtp
	  id <m0zsB8J-000A0tC>; Mon, 21 Dec 1998 20:36:47 +0100 (CET)
Received: by calle.in-berlin.de (Smail3.2.0.98)
	  id <m0zsB8F-000A0Sa>; Mon, 21 Dec 1998 20:36:43 +0100 (CET)
Message-ID: <367EA320.172C0858 at fhtw-berlin.de>
Date: Mon, 21 Dec 1998 20:36:00 +0100
From: "Klaus Heß" <khess at fhtw-berlin.de>
X-Mailer: Mozilla 4.05 [de]C-NECCK  (Win95; I)
MIME-Version: 1.0
To: linux-l at calle.in-berlin.de
Subject: linux-l: wait_queue is bad 
References: <19981221183105.N30512 at hoshi.in-berlin.de>
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: owner-linux-l at calle.in-berlin.de
Reply-To: linux-l at calle.in-berlin.de
Status: O
Content-Length: 2035
Lines: 43

Hat wer Ahnung was der Dichter mir damit sagen wollte bzw. wie kann ich
das verhindern ?

in /var/log/warn stand folgendes:

Dec 10 03:22:46 server kernel: wait_queue is bad (eip = 00126e21)
Dec 10 03:22:46 server kernel:         q = 0038ffe0
Dec 10 03:22:46 server kernel:        *q = 0038fffc
Dec 10 03:22:51 server kernel: wait_queue is bad (eip = 00126fec)
Dec 10 03:22:51 server kernel:         q = 0038ffe0
Dec 10 03:22:51 server kernel:        *q = 07dd6f1c
Dec 10 03:22:51 server kernel: general protection: 0000
Dec 10 03:22:51 server kernel: CPU:    0
Dec 10 03:22:51 server kernel: EIP:    0010:[__wait_on_page+140/176]
Dec 10 03:22:51 server kernel: EFLAGS: 00010092
Dec 10 03:22:51 server kernel: eax: f0007be0   ebx: 07dd6f1c   ecx:
0038fffc   edx: f0007be0
Dec 10 03:22:51 server kernel: esi: 00000246   edi: 07dd6f1c   ebp:
00201c1c   esp: 07dd6f10
Dec 10 03:22:51 server kernel: ds: 0018   es: 0018   fs: 002b   gs:
002b   ss: 0018
Dec 10 03:22:51 server kernel: Process tifftopnm (pid: 9757, process nr:
62, stackpage=07dd6000)
Dec 10 03:22:51 server kernel: Stack: 0038ffc0 07318800 07318800
055f7810 0038fffc 0011d822 0038ffc0 00000000 
Dec 10 03:22:51 server kernel:        04520550 40154000 05f7a058
00007000 07318800 00000000 0011ada3 05f7a058
Dec 10 03:22:51 server kernel:        40154000 00000000 0011aca0
40154000 042e5798 055f7810 00001000 00000000 
Dec 10 03:22:51 server kernel: Call Trace: [filemap_nopage+626/736]
[do_no_page+259/808] [do_no_page+0/808] [sys_write+331/388]
[do_page_fault+284/736] [do_page_fault+0/736] [do_bottom_half+59/96] 
Dec 10 03:22:51 server kernel:        [error_code+64/80] 
Dec 10 03:22:51 server kernel: Code: 8b 42 04 39 d8 74 05 89 c2 eb f5 90
89 4a 04 56 9d a1 38 12 

Der Fehler trat in der Abarbeitung eines unendlich langen Batch-Files
auf und nicht zum ersten Mal.
Nach meiner Meinung sieht es so aus, als ob ein Batch-Kdo. ein anderes
überholt.
Im XOSVIEW ist noch zu sehen wie im LOAD-Balken der Procs-Parameter
hochläuft.
Endresultat ist: Es geht gar nichts mehr.