davis@ee.iastate.edu (Jim Davis) (12/26/90)
erekose@apple.com (Erik Scheelke) writes: >I am looking for any information about the following panic that occurs >occasionally on my system: >PANIC: Kernel mode trap type 0x0000000e >Has anyone else every seen this? I am using Intel's version of AT&T Unix >System V 3.2.2. I have their TCP/IP and NFS installed also. The reason >I mention this is that there is a small correlation between when the panic >occurs and network traffic into (not out from tho...) the system. >Can anyone explain what causes a Kernel mode trap in general? Type 0x0e? >Thank you for any help! >Erik Scheelke I had the same type of trap with version 3.2.1. In my case, I think I didn't have enough stream data buffers allocated, so when network traffic got out of hand, the system crashed. You can check to see if this is a problem by running "crash" as root and typing "strstat". This will give you a list of stream buffers (by size) and what the high water mark is. The default was 384 buffers for the 64-byte and 128-byte buffers, and I gradually increased that to 1024 for each before it stopped crashing. Sometime later, I installed 3.2.2 and the system strated crashing again, so I'll have to do this again. Good Luck! Jim Davis davis@isuee1.ee.iastate.edu
umbalnea@ccu.umanitoba.ca (Scott L. Balneaves) (12/27/90)
In article <47590@apple.Apple.COM> erekose@apple.com (Erik Scheelke) writes: >I am looking for any information about the following panic that occurs >occasionally on my system: I work with SCO Unix v 3.2.2 where I work, so this may or may not be of help, but... An SCO box that we had was connected to a SUN network, and used as a gateway. We found that we would get intermittant network crashes, and sometimes, the whole SCO box would go down. We finally found (after much hair pulling) that the "Reccomended" TCP/IP STREAMS buffers we way too low. Specifically, the NSTREAMS kernal parameter, and the NBLK4092 and NBLK1024 parameters. I don't know what you have to do to change these kernal parms on your system, but I would suggest bumping them up by 20-30%, monitoring the system, and then lowering the buffers that are not being used. On SCO, there's a system util. called crash (ADM) that allows you to look into the kernal to see buffer allocations, etc. If you have something like this on your system, it may be invaluable. Hope this helps! Scott
soward@ms.uky.edu (John Soward) (12/29/90)
erekose@apple.com (Erik Scheelke) writes: >I am looking for any information about the following panic that occurs >occasionally on my system: >PANIC: Kernel mode trap type 0x0000000e >Has anyone else every seen this? I am using Intel's version of AT&T Unix >System V 3.2.2. I have their TCP/IP and NFS installed also. The reason >I mention this is that there is a small correlation between when the panic >occurs and network traffic into (not out from tho...) the system. >Can anyone explain what causes a Kernel mode trap in general? Type 0x0e? >Thank you for any help! >Erik Scheelke I too get a trap type 'e', running sysV4.0...some mention of this problem on the net earlier pointed me to the conclusion that it is the ethernet board we were using...are you using a Western Disgital board (or one that uses the wd chipset) if so then I would think that is the problem (although the software could be more patient) if not then it is a definite software glitch.... Mostly I get this error on Boot and after adjusting some buffer parameters, rarely, if ever get it during normal operation... -- ________________________________________________________________________ / 'She was so absolutely Digital...' / / John@ukpr.uky.edu | soward@s.ms.uky.edu | sysjohn@ukcc.uky.edu / /_______________________________________________________________________/
jerry@altos86.Altos.COM (Jerry Gardner) (01/04/91)
erekose@apple.com (Erik Scheelke) writes: >I am looking for any information about the following panic that occurs >occasionally on my system: > >PANIC: Kernel mode trap type 0x0000000e > >Can anyone explain what causes a Kernel mode trap in general? Type 0x0e? A kernel mode trap occurs when the UNIX kernel services a trap when it's running in kernel mode (as opposed to user mode). There are many things that cause a trap on the 386. A few examples are single-step trap, extension error, general protection violation, breakpoint, and page fault, to name a few. The kernel contains code to attempt to deal with each of these traps. If it cannot recover from the trap, the default case is to display the registers and panic. A kernel mode trap, type 0x0e is a page fault trap that occured while the the system was running on the kernel stack (in kernel mode). Since the kernel is not paged, a page fault occuring in kernel mode is generally fatal. The exception is when the kernel is moving data to or from a user's process space on behalf of that process. In this case, the kernel will try to validate the user page and retry the access. If it can't validate the page, it fails the system call that caused the access. A page fault trap in user mode is a more normal occurance. In this case, the kernel will simply try to read in the page that faulted and retry the operation. If the page isn't part of the processes address space, the kernel will send a signal (SIGSEGV) to the process. This does not result in a panic. What causes a kernel mode trap, type 0x0e? The most common cause is a bug in the kernel that causes it to access a memory location not mapped by a page table. A common cause of this is an uninitialized pointer or some other bogus pointer reference. You should probably report the circumstances of the trap to the vendor of your OS. Try to write down the contents of the system registers at the time of the trap as these contain important clues relating to the cause of the trap. In particular, CR2 contains the linear address of the memory reference that caused the trap and EIP is the program counter location at the time of the trap. -- Jerry Gardner, NJ6A Altos Computer Systems UUCP: {sun|pyramid|sco|amdahl|uunet}!altos!jerry 2641 Orchard Parkway Internet: jerry@altos.com San Jose, CA 95134 Guns don't kill people, bullets do. (408) 432-6200