-----------------
Original Posting:
-----------------
> Hi
>
> Yesterday one our 3/280 Suns crashed with the following message:
>
> Jan 10 09:37:18 ra vmunix: panic: segkmem_badop
>
> Does anyone know what this means? We are running SunOS 4.0.3.
> Thanks.
>
> Karen
---------
Solution:
---------
This is bug in the mbuf management code which is fixed in SunOS 4.1.
Thanks to:
Ray Smith (rcsmith@anagld.analytics.com)
Guy Harris (auspex!guy@uunet.uu.net)
Karen
===============================================
Karen Fulcher Scholz
GE Corporate Research and Development
Schenectady, New York
fulcher@crd.ge.com
-------------------
More detailed info:
-------------------
----- Begin Included Message -----
Howdy Karen,
I ran your error message through my full-text database
system of Sun related stuff and came up with the following message
which explains the problem. It is evidently fixed in 4.1.
Hope it helps,
Ray
P.S. In case you were wondering the database is made up of about
3 years of messages from sun-spots, sun-nets, sun-managers,
sun-flash and various usenet sources.
----------------------
BEGIN INCLUDED MESSAGE
----------------------
From: mike@jpl-devvax.JPL.NASA.GOV (Mike Tankenson)
Newsgroups: comp.sys.sun
Subject: Followup to Sun panic crash problem w/ p80 & UDP
Keywords: SunOS
Message-ID: <4393@brazos.Rice.edu>
Date: 20 Jan 90 20:32:34 GMT
Organization: Sun-Spots
Lines: 29
X-Sun-Spots-Digest: Volume 9, Issue 12, message 5 of 12
In Article 322 of comp.sys.proteon, I described a problem causing Sun
panic crashes that appeared to be related to high speed UDP streams over a
PRONET-80 interface:
When sending UDP streams from one Sun to the other Sun, we panic crash the
receiving Sun with a 'panic: segkmem_badop'. This is very repeatable. In
fact, repeat by using the 'ttcp' program from BRL, and send a high speed
UDP stream from one Sun to the other. The first session will complete Ok.
The next time that you try to start the 'ttcp' into receive mode:
ttcp -r -u ... &
The Sun will panic crash.
According to a former network software developer at Sun:
"This is a bug in the mbuf management code that was fixed in SunOS 4.1
about a year ago. There was an off-by-one error in the checking for
overflows of the cluster mbuf area. Just one of several bugs fixed when
we did some performance work on the basic networking code."
So it appears that this is a bug in SunOS 4.0.3, fixed in 4.1, but not yet
released. My local Sun technical support guru has provided me with a
patch to 4.0.3 for Sun3s and Sun4s (not tested yet). I hesitate to
blindly distribute any non-Sun patches, so if anyone is seeing similiar
problems with high speed UDP steams and wants a copy, let me know.
Mike Tankenson
ARPA: mike@jpl-devvax.JPL.NASA.GOV UUCP: seismo!cit-vax!jpl-devvax!mike
--
Ray Smith | Analytics, Inc.
rcsmith@analytics.com | 9891 Broken Land Parkway
{uunet,aplcen,wb3ffv,sundc}!anagld!rcsmith | Columbia, MD 21046
RCSmith@DOCKMASTER.NCSC.MIL | 301-381-4300
----- End Included Message -----
>From Guy:
It probably means you either have a hardware problem or a kernel bug.
Basically, the virtual memory subsystem supports various types of
objects that can "back up" various portions of a process's address
space. "seg_vn" handles parts backed up by files; "seg_kmem" handles
various bits of the kernel's address space. There is a set of
operations that those objects support, some of which aren't provided by
all the objects; apparently, the system tried to invoke one of the
operations that the "seg_kmem" segment *doesn't* support.
In general, most "panic" messages mean something only to the people who
developed and implemented the code that paniced, or are otherwise
familiar with that code; this one is no exception. If nobody says "oh
yeah, this is a known problem", report it to Sun.
----- End Included Message -----
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:09 CDT