Kernel error

[R.Palland]

Hello,

I have an proliant 6500 server with sco 5.0.5. (256MB ram)
about 8, 10 times a year the server is automaticly shutdown an then have an
autoboot.
The message on the console is "Kernel error trap....trying to dump
......pages. Cannot dump ....pages.
Then the reboot starts.
I'm trying to debug this problem.
I use the "crash" tool en by the option panic i got:
No Panic;
NOTICE: growrficient memory to allocate 294119 pages - system call failed.
I looked in the TA's en find something i can use,
the scodb tool. but i cant solve the problem or I don't know how to do it,
using this tool.

1- Who can tell me how to use and debug this problem with the scodb tool?
2- Can i make a kernel parameter larger so all the pages can be dumped?
and the system doesn't have an autoboot?
3- Are there some other tools I can use checking the filesystem and
debugging problems?
4 Is it an option to make the swap larger so the pages can be dumped?

Thanks,

Robert

[Tony Lawrence]

R.Palland wrote:
> Hello,
>
> I have an proliant 6500 server with sco 5.0.5. (256MB ram)
> about 8, 10 times a year the server is automaticly shutdown an then have an
> autoboot.
> The message on the console is "Kernel error trap....trying to dump
> ......pages. Cannot dump ....pages.
> Then the reboot starts.
> I'm trying to debug this problem.

Any particular reason?

Do you have kernel and driver source? Are you suspicious of some
particular driver? If so, is it something you wrote or can fix?

If not, chances are that this is a hardware issue. See
http://aplawrence.com/Unixart/trape.html for example.

Certain traps (0E for example) are almost always hardware. Others are
known to be associated with certain drivers or lack of patches etc. (
http://stage.caldera.com/cgi-bin/ssl_reference?105532 for example)

If it happens sporadically like this, it's very likely hardware. It's
always possible that it's still software, but much more likely to be
hardware..

--

Please note new phone number: (781) 784-7547

Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html

[Tony Lawrence]

I wrote:

> If not, chances are that this is a hardware issue. See
> http://aplawrence.com/Unixart/trape.html for example.
>
> Certain traps (0E for example) are almost always hardware. Others
> are known to be associated with certain drivers or lack of patches
> etc. ( http://stage.caldera.com/cgi-bin/ssl_reference?105532 for
> example)
>
> If it happens sporadically like this, it's very likely hardware.
> It's always possible that it's still software, but much more likely
> to be hardware..

Bela pointed out that I shouldn't be so adamant about "almost always
hardware". The http://aplawrence.com/Unixart/trape.html article does
explain that more fully, but he's right: an out of context statement
like that will probably be misinterpreted and cause no end of trouble
down the road.

It is true that my field experience with trape E's is that they are
almost always hardware. This is especially true when a system has been
running fine and (without software changes) suddenly starts panicing.
In this case also, given the sporadic nature, a good bet would be on
hardware. But (as I said) it still CAN be drivers or kernel bugs.