Page 1 of 1
Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 11:37
by doodie
Hi,
seit ein paar Wochen betreibe ich einen FTP-Server (Debian Woody), bei dem häufig Neue Benutzer erstellt, andere gelöscht und viele scriptgesteuert (Perl) aktualisiert werden. Dazu verwende ich diese Shell-Befehle:
Seit dem bekomme ich immer wieder Fehlermeldungen wie
Code: Select all
usermod: [username] not found in /etc/passwd
usermod: [username] not found in /etc/shadow
Das habe ich dann mit vipw erledigt, indem ich den Benutzer gelöscht und manuell nochmal angelegt habe. Bevor ich die Lösung mit vipw gefunden habe, dachte ich, dass der nscd-Cache möglicherweise nicht richtig geleert wird und da am Wochenende auf dem Server wenig los ist, habe ich ihn einfach mal neu gestartet (shutdown -r now). Leider ist der Server nicht mehr hochgefahren und musste per Reset-Knopf nochmal neu gestartet werden - in der /var/log/kernel.log stand folgendes drin:
Code: Select all
Nov 27 18:59:48 ftp kernel: Unable to handle kernel paging request at virtual address 723a8150
Nov 27 18:59:48 ftp kernel: printing eip:
Nov 27 18:59:48 ftp kernel: c0145697
Nov 27 18:59:48 ftp kernel: *pde = 00000000
Nov 27 18:59:48 ftp kernel: Oops: 0000
Nov 27 18:59:48 ftp kernel: CPU: 0
Nov 27 18:59:48 ftp kernel: EIP: 0010:[remove_inode_dquot_ref+63/124] Not tainted
Nov 27 18:59:48 ftp kernel: EFLAGS: 00010202
Nov 27 18:59:48 ftp kernel: eax: 00000002 ebx: 723a8120 ecx: d6116d90 edx: d6116e74
Nov 27 18:59:48 ftp kernel: esi: f507df4c edi: f6ec1800 ebp: f507df4c esp: f507df18
Nov 27 18:59:48 ftp kernel: ds: 0018 es: 0018 ss: 0018
Nov 27 18:59:48 ftp kernel: Process quotaoff (pid: 11336, stackpage=f507d000)
Nov 27 18:59:48 ftp kernel: Stack: d6116d98 f6ec1884 c01420e1 d6116d90 00000000 f507df4c 00000000 f6ec1884
Nov 27 18:59:48 ftp kernel: 00000000 f6ec1800 f6ec1860 f6ec1868 00000009 f5c788a0 f23a8de0 c0146725
Nov 27 18:59:48 ftp kernel: f6ec1800 00000000 00006000 00000200 00000000 f507dfa4 f6ec189c 00006000
Nov 27 18:59:48 ftp kernel: Call Trace: [remove_dquot_ref+109/300] [quota_off+137/224] [sys_quotactl+508/787] [sys_munmap+52/
60] [system_call+51/56]
Nov 27 18:59:48 ftp kernel:
Nov 27 18:59:48 ftp kernel: Code: 8b 43 30 83 f8 01 75 27 74 0e 50 68 60 83 2c c0 e8 a4 00 fd
Nov 27 18:59:48 ftp kernel: Kernel logging (proc) stopped.
Nov 27 18:59:48 ftp kernel: Kernel log daemon terminating.
So ganz im Allgemeinen läuft die Kiste ziemlich buggy und ich habe den Verdacht, das vielleicht mit dem Arbeitsspeicher was nicht stimmen könnte - ist das möglich? Oder die Festplatte? Weiss vielleicht jemand was mit den Eintragungen aus der kernel.log was anzufangen?
Ciao
nd
<edit>
PS: Hab' mir gerade nochmal ein paar Benutzer, die schon wieder buggy sind, via vipw genau angesehen und festgestellt, dass aus irgend einem Grund deren Zeile in der /etc/passwd und / oder /etc/shadow ziemlich zerschossen ist, weil z.B. anstatt einem Doppelpunkt ein z als Spaltentrenner reingeschrieben wurde... Misteriös...
</edit>
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 14:00
by kase
Sieht mir fast etwas nach einem defekten Filesystem / einer defekten Festplatte aus, aber warte lieber noch mal auf Aussagen von welchen, die sich mit so Sachen etwas besser auskennen.
Zumindest die korrupten Files und das mehrfache Auftauchen von "inode" und "ref" im Panic sieht IMHO etwas danach aus.
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 14:14
by tally
War denn die Kiste zu Beginn stabil, sprich hast Du einen vernünftigen BurnIn-Test laufen lassen, z.B. mit parallelen Kernel-Compiles, bevor Du sie produktiv eingesetzt hast? Ansonsten kann es eigentlich alles sein: defekter CPU-Lüfter, RAM, HD usw.
tally
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 14:21
by tally
Ach ja, wenn die Hardware einigermaßen aktuell ist und Du keinen direkten Zugriff auf die Hardware haben solltest, kannst Du ja mal mit lm_sensors und den smartmontools schauen, ob Du etwas auffälliges siehst.
BTW, das Subject halte ich nicht für besonders glücklich, keine Disti läuft auf kaputter Hardware stabil.
tally
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 17:03
by doodie
Hi!
@kase:
ACK - ein paar Sachen bzgl. FS stehen da drin... Aber ob das was zu bedeuten hat (bzw. was) ist halt jetzt die Frage.
@tally:
Das Subject ist zustande gekommen, nachdem ich feststellte, dass ich massig Probleme mit dem Usermanagement habe und ich im WWW diverse Informationen über Fehler in useradd etc. gefunden habe. Okay, ich werd's ändern, falls das noch geht...
Die smartmontools habe ich gerade installiert und einen Test mit
Code: Select all
smartctl -s on -t long /dev/hda >smartctl.log
gestartet. Ich hoffe, er schreibt mir das Testergebnis irgendwie in die Datei rein, falls meine SSH-Verbindung zwischendurch gekillt wird. So gegen 18 Uhr ist er fertig, sagt er mir...
Auf die Hardware habe ich leider keinen Zugriff, aber (einigermaßen) aktuell sein sollte sie schon.
> BurnIn-Test laufen lassen, z.B. mit parallelen Kernel-Compiles
Wa??? Da muss ich passen... Aber ich denke für die Zukunft werde ich mir ein paar Tests einfallen lassen, bevor ich mit so'ner Kiste produktiv an den Start gehe. Die Probleme hatte ich von Anfang an, wurden nur in den letzten Tagen häufiger.
Ich hoffe mal, dass die Festplatte in Ordnung ist, sonst bekomme ich die Kriese, weil
a) ca. 40 GB Daten drauf sind und die erstmal gesichert sein wollen
b) ich bei einem Festplattentausch wohl das komplette System neu installieren darf und der Server wohl ein paar Stunden bis Tage offline sein wird - das zu argumentieren ist halt für mich etwas schwierig...
Bin ja im Grunde selbst schuld, wenn's soweit kommt. Also ich melde mich wieder hier an dieser Stelle sobald der Test geschafft ist oder ich irgendwelche anderen Ergebnisse habe. Bis dahin dankeschön und
ciao
nd
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 17:34
by tally
@doodie
Ã?h, das habe ich nicht explizit geschrieben aber das sollte doch eigentlich klar sein: wenn Du wichtige Daten auf dem System und kein Backup hast, dann ist jetzt definitiv nicht der richtige Zeitpunkt für Tests. Dann heißt es als allererstes Daten sichern. Mit jeder Aktivität riskierst Du das Dateien verändert werden bzw. Daten teilweise oder ganz verloren gehen.
Mit den smartmontools hättest Du Dir eigentlich nur das Errorlog der HD ansehen sollen.
tally
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 18:07
by doodie
Hi tally,
na klar - passt scho'... Bei dem Server ist es nicht sooo dringend alle Daten zu sichern, bevor ich einen Befehl eintippe. Jetzt mal so auf die Schnelle 40 Gig übers Netz zu schieben ist halt auch eine Zeit- / Kostenfrage... Bevor ich bewusst wirklich kritische Aktionen starte, überleg' ich's mir nochmal mit der Dasi.
Also
gibt mir (nachdem ich noch schnell einen kurzen Selbsttest gestartet habe):
Code: Select all
smartctl version 5.26 Copyright (C) 2002-3 Bruce Allen
Home page is http://smartmontools.sourceforge.net/
=== START OF INFORMATION SECTION ===
Device Model: SAMSUNG SV1203N
Serial Number: S01CJ10X643436
Firmware Version: TQ100-24
Device is: In smartctl database [for details use: -P show]
ATA Version is: 7
ATA Standard is: ATA/ATAPI-7 T13 1532D revision 0
Local Time is: Sun Nov 28 17:58:37 2004 CET
==> WARNING: Contact developers at smartmontools-support@lists.sourceforge.net; may need -F samsung[2] enabled.
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x00) Offline data collection activity was
never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (5400) seconds.
Offline data collection
capabilities: (0x1b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
No Conveyance Self-test supported.
No Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
No General Purpose Logging support.
Short self-test routine
recommended polling time: ( 1) minutes.
Extended self-test routine
recommended polling time: ( 90) minutes.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 253 253 000 Pre-fail Always - 0
4 Start_Stop_Count 0x0032 253 253 000 Old_age Always - 0
5 Reallocated_Sector_Ct 0x0033 253 253 010 Pre-fail Always - 0
7 Seek_Error_Rate 0x000b 253 253 051 Pre-fail Always - 0
8 Seek_Time_Performance 0x0024 253 253 000 Old_age Offline - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 4828
10 Spin_Retry_Count 0x0013 253 253 049 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 253 253 000 Old_age Always - 0
194 Temperature_Celsius 0x0022 133 133 000 Old_age Always - 35
195 Hardware_ECC_Recovered 0x000a 100 100 000 Old_age Always - 8536321
196 Reallocated_Event_Count 0x0012 253 253 000 Old_age Always - 0
197 Current_Pending_Sector 0x0033 253 253 010 Pre-fail Always - 0
198 Offline_Uncorrectable 0x0031 253 253 010 Pre-fail Offline - 0
199 UDMA_CRC_Error_Count 0x000b 253 253 051 Pre-fail Always - 0
200 Multi_Zone_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0
201 Soft_Read_Error_Rate 0x000b 100 100 051 Pre-fail Always - 0
SMART Error Log Version: 1
Warning: ATA error count 4608 inconsistent with error log pointer 5
ATA Error Count: 4608 (device log contains only the most recent five errors)
CR = Command Register [HEX]
FR = Features Register [HEX]
SC = Sector Count Register [HEX]
SN = Sector Number Register [HEX]
CL = Cylinder Low Register [HEX]
CH = Cylinder High Register [HEX]
DH = Device/Head Register [HEX]
DC = Device Command Register [HEX]
ER = Error register [HEX]
ST = Status register [HEX]
Timestamp = decimal seconds since the previous disk power-on.
Note: timestamp "wraps" after 2^32 msec = 49.710 days.
Error 4608 occurred at disk power-on lifetime: 39 hours
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
04 51 00 00 4f c2 e0 Error: ABRT
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Timestamp Command/Feature_Name
-- -- -- -- -- -- -- -- --------- --------------------
b0 da 00 00 4f c2 e0 00 81983.625 SMART RETURN STATUS
20 00 08 fb 7e 1b eb 00 81983.625 READ SECTOR(S)
20 00 f8 03 7e 1b eb 00 81983.563 READ SECTOR(S)
ec 00 00 02 7e 1b e0 00 81983.563 IDENTIFY DEVICE
20 00 08 fb 7d 1b eb 00 81983.563 READ SECTOR(S)
Error 4607 occurred at disk power-on lifetime: 18 hours
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
04 51 00 01 4f c2 a0 Error: ABRT
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Timestamp Command/Feature_Name
-- -- -- -- -- -- -- -- --------- --------------------
b0 d9 00 01 4f c2 a0 00 8.313 SMART DISABLE OPERATIONS
ec 00 ff 01 00 00 a0 00 8.313 IDENTIFY DEVICE
10 00 ff 01 00 00 a0 00 8.313 RECALIBRATE [OBS-4]
91 00 ff 01 00 00 af 00 8.313 INITIALIZE DEVICE PARAMETERS [OBS-6]
ec 00 ff 01 00 00 a0 00 8.313 IDENTIFY DEVICE
Error 4606 occurred at disk power-on lifetime: 18 hours
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
04 51 00 01 4f c2 a0 Error: ABRT
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Timestamp Command/Feature_Name
-- -- -- -- -- -- -- -- --------- --------------------
b0 d9 00 01 4f c2 a0 00 8.313 SMART DISABLE OPERATIONS
ec 00 ff 01 00 00 a0 00 8.313 IDENTIFY DEVICE
10 00 ff 01 00 00 a0 00 8.313 RECALIBRATE [OBS-4]
91 00 ff 01 00 00 af 00 8.313 INITIALIZE DEVICE PARAMETERS [OBS-6]
ec 00 ff 01 00 00 a0 00 8.313 IDENTIFY DEVICE
Error 4605 occurred at disk power-on lifetime: 18 hours
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
04 51 00 01 4f c2 a0 Error: ABRT
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Timestamp Command/Feature_Name
-- -- -- -- -- -- -- -- --------- --------------------
b0 d9 00 01 4f c2 a0 00 8.500 SMART DISABLE OPERATIONS
ec 00 ff 01 00 00 a0 00 8.500 IDENTIFY DEVICE
10 00 ff 01 00 00 a0 00 8.500 RECALIBRATE [OBS-4]
91 00 ff 01 00 00 af 00 8.500 INITIALIZE DEVICE PARAMETERS [OBS-6]
ec 00 ff 01 00 00 a0 00 8.438 IDENTIFY DEVICE
Error 4604 occurred at disk power-on lifetime: 18 hours
When the command that caused the error occurred, the device was active or idle.
After command completion occurred, registers were:
ER ST SC SN CL CH DH
-- -- -- -- -- -- --
04 51 00 01 4f c2 a0 Error: ABRT
Commands leading to the command that caused the error were:
CR FR SC SN CL CH DH DC Timestamp Command/Feature_Name
-- -- -- -- -- -- -- -- --------- --------------------
b0 d9 00 01 4f c2 a0 00 70983.500 SMART DISABLE OPERATIONS
ec 00 ff 01 00 00 a0 00 70983.500 IDENTIFY DEVICE
10 00 ff 01 00 00 a0 00 70983.500 RECALIBRATE [OBS-4]
91 00 ff 01 00 00 af 00 70983.500 INITIALIZE DEVICE PARAMETERS [OBS-6]
ec 00 ff 01 00 00 a0 00 70983.500 IDENTIFY DEVICE
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Short offline Completed without error 00% 40 -
Zugegeben, das sagt mir auch nicht sooo viel, sieht aber für meine Begriffe recht gut aus!?
Ciao
nd
PS: Okay, dass in smartctl.log nicht viel drin stehen wird, hab' ich jetzt auch gerafft
Kann es sein, dass mein erster long-Test gar nicht gestartet wurde? Der steht nämlich nicht in der Liste am Ende der Ausgabe...
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 18:27
by tally
@doodie
Du wirst schon wissen was Du tust.
Die HD scheint wohl i.O. zu sein. Wenn Du einen kleinen Streßtest haben willst, kannst Du den hier probieren. Das Boardmitglied Walsleben kann damit seinen Rooti ziemlich schnell zum Absturz bringen. Die Zeile macht einen rekursiven ls auf / und übergibt das Ergebnis direkt an bzip2 zum packen. Je nach Prozessanzahl erzeugt es eine ganz nette Last und läuft auch ins swap. Die Schleifenzahl liegt standardmäßig auf 3 und Du kannst sie nach Deinem Gefühl erhöhen. Verfolgen kannst Du alles mit top.
Code: Select all
typeset -i i=0 ; while [ $((i++)) -lt 3 ] ; do ls -laR / 2>&1 | bzip2 -qf9 - > lslaR$i.bz2 & done
Ob Du diesen Test risikierst mußt Du selbst entscheiden und verantworten ;-)
tally
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 19:09
by doodie
Hi tally,
wissen was man tut ist meistens irgendwo relativ (btw wissen was frau tut häufig auch
). Also ich traue mich mal und starte erstmal die 3...
...
Was denn, schon fertig? Das war zu schnell. 50...
...
Der Server ist seinen Preis wert :-D 99...
...
...
Hmmmm... top:
Code: Select all
Mem: 900080K total, 862408K used, 37672K free, 28632K buffers
Hmmmm... 500...
...
...
...
...
...
...
Hoppla:
Code: Select all
bzip2: Caught a SIGSEGV or SIGBUS whilst compressing.
Possible causes are (most likely first):
(1) This computer has unreliable memory or cache hardware
(a surprisingly common problem; try a different machine.)
(2) A bug in the compiler used to create this executable
(unlikely, if you didn't compile bzip2 yourself.)
(3) A real bug in bzip2 -- I hope this should never be the case.
The user's manual, Section 4.3, has more info on (1) and (2).
If you suspect this is a bug in bzip2, or are unsure about (1)
or (2), feel free to report it to me at: jseward@acm.org.
Section 4.3 of the user's manual describes the info a useful
bug report should have. If the manual is available on your
system, please try and read it before mailing me. If you don't
have the manual or can't be bothered to read it, mail me anyway.
Und was später:
Code: Select all
bzip2/libbzip2: internal error number 1007.
This is a bug in bzip2/libbzip2, 1.0.2, 30-Dec-2001.
Please report it to me at: jseward@acm.org. If this happened
when you were using some program which uses libbzip2 as a
component, you should also report this bug to the author(s)
of that program. Please make an effort to report this bug;
timely and accurate bug reports eventually lead to higher
quality software. Thanks. Julian Seward, 30 December 2001.
[52] 23800
*** A special note about internal error number 1007 ***
Experience suggests that a common cause of i.e. 1007
is unreliable memory or other hardware. The 1007 assertion
just happens to cross-check the results of huge numbers of
memory reads/writes, and so acts (unintendedly) as a stress
test of your memory system.
I suggest the following: try compressing the file again,
possibly monitoring progress in detail with the -vv flag.
* If the error cannot be reproduced, and/or happens at different
points in compression, you may have a flaky memory system.
Try a memory-test program. I have used Memtest86
(www.memtest86.com). At the time of writing it is free (GPLd).
Memtest86 tests memory much more thorougly than your BIOSs
power-on test, and may find failures that the BIOS doesn't.
* If the error can be repeatably reproduced, this is a bug in
bzip2, and I would very much like to hear about it. Please
let me know, and, ideally, save a copy of the file causing the
problem -- without which I will be unable to investigate it.
Liegt das jetzt an bzip2 oder der Maschine??? Mein Verdacht auf defekten Arbeitsspeicher verhärtet sich langsam. Test mit 500 läuft noch...
Ciao
nd
<edit>
Hmmmm... Zum Thema Swap (jetzt so ca. bei 285):
Code: Select all
Mem: 900080K total, 892840K used, 7240K free, 19520K buffers
Swap: 0K total, 0K used, 0K free, 8884K cached
</edit>
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 19:23
by tally
Ist bestimmt ein Hardwareproblem. Aber wo das Problem genau liegt ist dann meistens sehr schwer zu lokalisieren und vor allem sehr zeitaufwendig. Defektes RAM, überhitztes RAM, defekter/verschmutzter CPU-Lüfter, allgemein zu hohe Umgebungstemperatur usw. Auf jeden Fall keine schöne Sache.
tally
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 19:33
by tally
Code: Select all
Mem: 900080K total, 892840K used, 7240K free, 19520K buffers
Swap: 0K total, 0K used, 0K free, 8884K cached
Hast Du gar keinen swap aktiviert?
tally
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 19:41
by doodie
Hi tally,
ok, also die 500 hat er jetzt gestartet und auf zwei SSH Konsolen läuft top - aber nicht wirklich. Mit einer dritten Konsole versuche ich mich gerade anzumelden, aber irgendwie dauert das ewig (warum nur?
). Die Frage ist jetzt, ob der Server komplett steht, oder sich nochmal wieder erholt - Ping geht jedenfalls noch und SSH hat auch noch keine Konsole wegen unterbrochener Verbindung gekillt...
Also wenn Du auch von einem Hardware-Problem überzeugt bist, will ich es jetzt mal mit einem Arbeitsspeicher-Test probieren. Nun ist es ja so, dass memtest86 beim Booten läuft!? Ich habe das Tool noch nie ausprobiert, bin aber etwas skeptisch, weil da der lilo mit im Spiel ist, und da habe ich mir bei root-Servern mit Recovery-System schonmal die Finger verbrannt.
Wie funktioniert das mit memtest86? Wie komme ich an das Testergebnis, wenn das Tool beim Booten läuft? Gar nicht? Und wie verträgt sich das Tool mit Rechnern von 1&1 oder Server4Free und deren Recovery-Systemen?
Oder gibt es vielleicht noch eine alternative Möglichkeit den Arbeitsspeicher zur Laufzeit (also nach dem Booten) zu testen? Auch wenn das nicht DER 100%ige Test ist, der jeden Staubkrümel auf der Oberfläche des RAM-Bausteins bemängelt - wenn ich nur irgendeine Fehlermeldung bekomme, die eindeutig beweist, dass der Arbeitsspeicher einen Schuss hat, kann ich den Support des Rechenzentrums bemühen...
Auf jeden Fall Dir ein dickes DANKESCHÃ?N für Deine Mühe!
Ciao
nd
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 19:43
by doodie
Ooops... Da war noch was: Ich habe zum Installieren der Kiste das Script von roothell.org benutzt und dabei auch eine Swap-Partition eingerichtet, wenn ich mich nicht irre... Aber leider kann ich das gerade nicht prüfen, weil ich immer noch nicht wieder auf die Shell komme...
Ciao
nd
<edit>
Also die Kiste reagiert immer noch nicht. Ich muss jetzt mal eben nach Karlsruhe rüberdüsen, bin aber gegen 0 Uhr wieder im Lande und sehe dann auf jeden Fall nochmal nach dem Stand der Dinge...
</edit>
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-28 20:12
by tally
@doodie
Ohne swap könnte es ziemlich lange dauern, bis Deine Kiste für Dich wieder verfügbar ist.
Zu memtest86 kann ich Dir nichts sagen, habe ich noch nie benutzt. Mir reichen eigentlich solche Meldungen von bzip2 oder ein "signal 11" beim Kernel-Compile.
tally
Re: Unable to handle kernel paging request at virtual address...
Posted: 2004-11-29 00:06
by doodie
Hi tally,
ja, das merke ich gerade... Läuft wohl immer noch - naja, schaumermal, das kann ja nicht ewig dauern. Ich probier mal den Speicher aufgrund dieser Fehlermeldungen austauschen su lassen. Wenn die RZ-Techniker den Speicher getauscht haben und die Probleme nicht verschwunden sein sollten, poste ich hier wohl nochmal - bis dahin: Nochmals vielen Dank und
ciao
nd