Questions regarding a PANIC situation - SCO

This is a discussion on Questions regarding a PANIC situation - SCO ; Hi, Last week, we experienced 2 KERNEL PANIC error on our SCO Unix 5.0.7 server within a 2 hour span. So I called our sofware support which is OGC using running on an Informix Database. Within 5 minutes I had ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: Questions regarding a PANIC situation

  1. Questions regarding a PANIC situation

    Hi,

    Last week, we experienced 2 KERNEL PANIC error on our SCO Unix 5.0.7
    server within a 2 hour span. So I called our sofware support which is
    OGC using running on an Informix Database. Within 5 minutes I had as
    answer that the problem was an Hardware issue. Since the server is
    supported by another supplier, I then called them. They told me that
    such of a problem could be software as well. Not only hardware like
    the SCO site posts here.

    Why did my UNIX kernel "panic"?

    They mentionned for example that a FTP command could make the server
    PANIC! So I went back to the OGC software provider and told them that
    we couldn't find any evidence within logs and everything of the source
    of the problem happened that day. So How you could tell me in 5
    minutes that it was an Hardware issue? They answered that software
    means SCO Unix, NOT their software!!!!

    So my question is: Is a PANIC error could be the result of a software
    function or programming synthax or command other than the OS itself?
    Assuming it's not hardware of course.

    Thanks in advance.

    Adamsville2k

  2. Re: Questions regarding a PANIC situation

    On 2008-05-09, adamsville2k wrote:
    >
    > Last week, we experienced 2 KERNEL PANIC error on our SCO Unix 5.0.7
    > server within a 2 hour span. So I called our sofware support which is
    > OGC using running on an Informix Database. Within 5 minutes I had as
    > answer that the problem was an Hardware issue. Since the server is
    > supported by another supplier, I then called them. They told me that
    > such of a problem could be software as well. Not only hardware like
    > the SCO site posts here.


    More details would have been appropriate here - you usually have
    some indication of the source of the panic. However, the source
    is unlikely to be your application, unless possibly it is doing
    something nasty with raw memory via /dev/mem or something of that
    sort. Put simply, your application shouldn't be able to make the
    OS panic. It should reject any invalid requests made by system
    calls etc cleanly and without threatening the integrity of the
    system. This is generally what happens in reality. To do otherwise
    would be a security flaw in that it would present a potential DoS
    vector.

    So the source of the panic is somewhere within the OS kernel itself
    which doesn't have the same level of protection as userland
    applications. OSR507 itself is generally fairly stable and so I
    would tend to agree with your application provider that this is
    probably a hardware issue. Kernel mode drivers typically have
    limited error recovery built in to them but this is designed for
    errors in normally functioning kit. Since you can't in general
    anticipate what problems defective kit might throw up the drivers
    don't attempt to and panic if things get too confusing.

    --
    Andrew Smallshaw
    andrews@sdf.lonestar.org

  3. Re: Questions regarding a PANIC situation

    On 9 mai, 08:41, Andrew Smallshaw wrote:
    > On 2008-05-09, adamsville2k wrote:
    >
    >
    >
    > > Last week, we experienced 2 KERNEL PANIC error on our SCO Unix 5.0.7
    > > server within a 2 hour span. So I called our sofware support which is
    > > OGC using running on an Informix Database. Within 5 minutes I had as
    > > answer that the problem was an Hardware issue. Since the server is
    > > supported by another supplier, I then called them. They told me that
    > > such of a problem could be software as well. Not only hardware like
    > > the SCO site posts here.

    >
    > More details would have been appropriate here - you usually have
    > some indication of the source of the panic. *However, the source
    > is unlikely to be your application, unless possibly it is doing
    > something nasty with raw memory via /dev/mem or something of that
    > sort. *Put simply, your application shouldn't be able to make the
    > OS panic. *It should reject any invalid requests made by system
    > calls etc cleanly and without threatening the integrity of the
    > system. *This is generally what happens in reality. *To do otherwise
    > would be a security flaw in that it would present a potential DoS
    > vector.
    >
    > So the source of the panic is somewhere within the OS kernel itself
    > which doesn't have the same level of protection as userland
    > applications. *OSR507 itself is generally fairly stable and so I
    > would tend to agree with your application provider that this is
    > probably a hardware issue. *Kernel mode drivers typically have
    > limited error recovery built in to them but this is designed for
    > errors in normally functioning kit. *Since you can't in general
    > anticipate what problems defective kit might throw up the drivers
    > don't attempt to and panic if things get too confusing.
    >
    > --
    > Andrew Smallshaw
    > andr...@sdf.lonestar.org


    Thanks Andrew for replying. I know that there is few details here but
    the point is to find out who's wrong and who's right! So if "software"
    means SCO OS alone, it's fine to me. I just want ot make sure that
    applications don't make the KERNEL to panic.

    Adamsville2k

  4. Re: Questions regarding a PANIC situation

    adamsville2k wrote:
    > On 9 mai, 08:41, Andrew Smallshaw wrote:
    >> On 2008-05-09, adamsville2k wrote:
    >>
    >>
    >>
    >>> Last week, we experienced 2 KERNEL PANIC error on our SCO Unix 5.0.7
    >>> server within a 2 hour span. So I called our sofware support which is
    >>> OGC using running on an Informix Database. Within 5 minutes I had as
    >>> answer that the problem was an Hardware issue. Since the server is
    >>> supported by another supplier, I then called them. They told me that
    >>> such of a problem could be software as well. Not only hardware like
    >>> the SCO site posts here.

    >> More details would have been appropriate here - you usually have
    >> some indication of the source of the panic. However, the source
    >> is unlikely to be your application, unless possibly it is doing
    >> something nasty with raw memory via /dev/mem or something of that
    >> sort. Put simply, your application shouldn't be able to make the
    >> OS panic. It should reject any invalid requests made by system
    >> calls etc cleanly and without threatening the integrity of the
    >> system. This is generally what happens in reality. To do otherwise
    >> would be a security flaw in that it would present a potential DoS
    >> vector.
    >>
    >> So the source of the panic is somewhere within the OS kernel itself
    >> which doesn't have the same level of protection as userland
    >> applications. OSR507 itself is generally fairly stable and so I
    >> would tend to agree with your application provider that this is
    >> probably a hardware issue. Kernel mode drivers typically have
    >> limited error recovery built in to them but this is designed for
    >> errors in normally functioning kit. Since you can't in general
    >> anticipate what problems defective kit might throw up the drivers
    >> don't attempt to and panic if things get too confusing.
    >>
    >> --
    >> Andrew Smallshaw
    >> andr...@sdf.lonestar.org

    >
    > Thanks Andrew for replying. I know that there is few details here but
    > the point is to find out who's wrong and who's right! So if "software"
    > means SCO OS alone, it's fine to me. I just want ot make sure that
    > applications don't make the KERNEL to panic.
    >
    > Adamsville2k


    We can't be helpful here without more specific information - make and
    model of system, how old is it, how much RAM and disk, what other
    hardware is attached (EG Digiport serial ports, USB printers/disk drives
    etc. etc.)

    What patches have you applied? FYI The current Master Patch version for
    5.0.7 is MP5.

    Have you looked at the var/adm/syslog file to see if there's evidence of
    problems just before the PANIC? Ditto any logs maintained by your
    application?

    Any red lights on any disk drives in your RAID array (if you have one)?

    Finally, someone needs to write down all the info from the PANIC display
    on the system console - that info is only onscreen, because a PANIC
    stops SCO dead in it's tracks.

    --
    ----------------------------------------------------
    Pat Welch, UBB Computer Services, a WCS Affiliate
    SCO Authorized Partner
    Microlite BackupEdge Certified Reseller
    Unix/Linux/Windows/Hardware Sales/Support
    (209) 745-1401 Cell: (209) 251-9120
    E-mail: patubb@inreach.com
    ----------------------------------------------------

  5. Re: Questions regarding a PANIC situation


    "adamsville2k" wrote in message
    news:4d70ebe3-97d6-4473-bd34-9d80dd47d0df@r66g2000hsg.googlegroups.com...
    On 9 mai, 08:41, Andrew Smallshaw wrote:
    > On 2008-05-09, adamsville2k wrote:
    >
    >
    >
    > > Last week, we experienced 2 KERNEL PANIC error on our SCO Unix 5.0.7
    > > server within a 2 hour span. So I called our sofware support which is
    > > OGC using running on an Informix Database. Within 5 minutes I had as
    > > answer that the problem was an Hardware issue. Since the server is
    > > supported by another supplier, I then called them. They told me that
    > > such of a problem could be software as well. Not only hardware like
    > > the SCO site posts here.

    >
    > More details would have been appropriate here - you usually have
    > some indication of the source of the panic. However, the source
    > is unlikely to be your application, unless possibly it is doing
    > something nasty with raw memory via /dev/mem or something of that
    > sort. Put simply, your application shouldn't be able to make the
    > OS panic. It should reject any invalid requests made by system
    > calls etc cleanly and without threatening the integrity of the
    > system. This is generally what happens in reality. To do otherwise
    > would be a security flaw in that it would present a potential DoS
    > vector.
    >
    > So the source of the panic is somewhere within the OS kernel itself
    > which doesn't have the same level of protection as userland
    > applications. OSR507 itself is generally fairly stable and so I
    > would tend to agree with your application provider that this is
    > probably a hardware issue. Kernel mode drivers typically have
    > limited error recovery built in to them but this is designed for
    > errors in normally functioning kit. Since you can't in general
    > anticipate what problems defective kit might throw up the drivers
    > don't attempt to and panic if things get too confusing.
    >
    > --
    > Andrew Smallshaw
    > andr...@sdf.lonestar.org


    Thanks Andrew for replying. I know that there is few details here but
    the point is to find out who's wrong and who's right! So if "software"
    means SCO OS alone, it's fine to me. I just want ot make sure that
    applications don't make the KERNEL to panic.

    Adamsville2k

    Ok, let's look at this logically. Has your application EVER caused the
    system to 'panic' trap? My guess is 'NO'. Therefore, it is only logical to
    look elsewhere. Most times, when we experience panics, it's the direct
    result of something else having occurred ...... either the hardware has
    malfunctioned, someone has changed something in the OS, or maybe the lights
    flickered a few times. Like the others, there really isn't enough
    information here to make a sound decision on just what caused the panic, but
    it would be prudent to start looking at your hardware and make dead sure you
    have adequately backed up the important files. Kernel panics have a nasty
    habit of crashing systems.

    JP



  6. Re: Questions regarding a PANIC situation

    You really need to shift your focus away from "who can I blame for
    this" to what caused it and how to fix it.

    First go here, scroll all the way to the bottom and read the section
    on using the crash diagnostics.
    http://osr507doc.sco.com/en/OSAdminG/CONTENTS.html

    If you're the sysadmin you should know how to use this. If you didn't
    before, learn now. This is a well-defined procedure, but you must be
    ready to save a kernel dump before it happens, not days afterwards.
    Acting promptly when it happens is the only solution.

    If it were me, I would have already reseated all cards, memory and cpu
    chips on this system.

    You want to know if software can cause a kernel panic, and the answer
    is yes. It would be extremely rare for application software to do so,
    but it's possible for a driver to cause a panic. So have you checked
    every driver version and upgraded as necessary?

    Even with the latest driver, it's possible for circumstances to cause
    a crash. I vividly recall an incident several years ago when a
    client's system periodically panicked and crashed. There didn't seem
    to be any cause or pattern. They had had me setup a temporary remote
    office, running dumb terminals over a modem connection to a well-known
    multi-user serial card. They were printing some very long reports to
    a transparent printer over this connection. When a print job was
    running, if the modem connection dropped the system panicked and
    crashed. The only way I isolated this was by using the 'crash'
    procedure as documented. Yes it was technically caused by driver
    software, which solved nothing. Not printing reports of several
    hundred pages over this connection solved the problem.

    Good luck. Mark


    On May 9, 6:34*am, adamsville2k wrote:
    > Hi,
    >
    > Last week, we experienced 2 KERNEL PANIC error on our SCO Unix 5.0.7
    > server within a 2 hour span. So I called our sofware support which is
    > OGC using running on an Informix Database. Within 5 minutes I had as
    > answer that the problem was an Hardware issue. Since the server is
    > supported by another supplier, I then called them. They told me that
    > such of a problem could be software as well. Not only hardware like
    > the SCO site posts here.
    >
    > Why did my UNIX kernel "panic"?
    >
    > They mentionned for example that a FTP command could make the server
    > PANIC! So I went back to the OGC software provider and told them that
    > we couldn't find any evidence within logs and everything of the source
    > of the problem happened that day. So How you could tell me in 5
    > minutes that it was an Hardware issue? They answered that software
    > means SCO Unix, NOT their software!!!!
    >
    > So my question is: Is a PANIC error could be the result of a software
    > function or programming synthax or command other than the OS itself?
    > Assuming it's not hardware of course.
    >
    > Thanks in advance.
    >
    > Adamsville2k



+ Reply to Thread