Koozali.org: home of the SME Server
Legacy Forums => General Discussion (Legacy) => Topic started by: Claudia Siegner on February 06, 2003, 03:32:14 PM
-
Hello everybody,
it's me again
Just, when I posted my email, the server(SME 5.5Update2) crashed.
with
"...
Aiee, killing interrupt handler
Kernel panic Attempted to kill the idle task
In swapper task - not syncing"
I restarted the server and got
Checking root filesystem
/ was not cleanly unmounted, check forced
/:
Deleted inode 180579 has zero dtime. FIXED.
/:
Deleted inode 3578694 has zero dtime. FIXED.
The server has crashed about three times this year (not always with the same messages)
but always, when after the reboot the root filsystem was checked,
it was inode 180579, that was detected to have zero dtime
and the next inode was always in the range between 3578694 and 3578751.
Why is ist always the same inode?
and does anybody know, what the "crash-Message" means?
Thank you again,
Claudia.
-
Claudia, sorry I don't have an answer for you, only sympathy. I had a server crash this evening that resulted in lost data. The message was the same as yours -
Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task
In swapper task - not syncing
This client's system is SME 5.5U2 with no modifications except using dos filemode = yes in smb.conf for the main data folder which is an ibay. This system replaced a Windows 2000 server. The system has 1 gig of ram running on an ASUS motherboard with an AMD 2100+ processor (1.733 mhz). It supports 10+ users with occasional heavy data use - tax and accounting files. It had run without a problem for over three months.
I have managed to argue for the stability of Linux, but I am unable to explain this crash. Only three users were on the system at the time. Note that I have made a PPTP connection from an XP workstation through a 5.6 server to connect to this 5.5 server. While this connection was live at the time of the crash, no data was being transferred across the PPTP connection.
Before I start randomly replacing hardware, if there are specific logs that would help to explain this problem, I would appreciate being pointed in the right direction.
Thanks,
jim