Trap type 0xE (was: How do you use crash?)

Trap type 0xE (was: How do you use crash?)

Post by Chris Mille » Wed, 11 Oct 1995 04:00:00

This is almost certainly the infamous trap type 0x0000000E (a
page fault trap).

There are many possible causes, but in your case I would point a
finger of suspicion at the Digiboard and SCO's sio driver.
We have seen a series of such problems, all characterised by
dying in the siointr routine (not quite the same as your dump,
but close).

There is a recently-diagnosed problem with a 4-port dumb
Digiboard PC/X using the sio drivers (ODT2 through OSR5); I
suspect on slim evidence that it may depend on the Digiboard
revision as well (known problem with Rev K, cannot reproduce
with Rev M). SCO have given us a binary patch for this, and I
understand that they are working on an "official" patch.

If you have smart Digiboards or 8-port dumb PC/Xs, the
following does NOT apply.

It seems that under some circumstances of heavy load, the
Digiboard sets an extra bit in the register that is polled to
determine which port interrupted, and the sio driver does not
mask out this bit. In consequence, the kernel takes a blind
leap into hyperspace trying to get data from a non-existent

[ ... Description of crashes omitted ... ]


> Panic String: k_trap - Kernel mode trap type 0x%x

> > stat
> system name:    cms
> release:        3.2
> node name:      cms
> version:        2
> machine name:   i386
> time of crash:  Mon Oct  9 19:54:20 1995
> age of system:  10 day, 21 min.
> panicstr:       k_trap - Kernel mode trap type 0x%x
> > trace
> e0000c58  e0000c94  prf_task (e,f01790c4,1,1)
> e0000c9c  e0000cb4  cmn_err  (3,f0158138,e,f01790a0)
> e0000cbc  e0000ce4  k_trap   (e0000cf0)
> Trap e    e0000cf0  cmntrap  from f0023a94 in siogettc
>   ax:       0 cx:       5 dx:f01790fe bx:       0 fl:    10202
ds: 160 fs:   0
>   sp:e0000d20 bp:e0000d40 si:f01790a0 di:f01790c4 err:       0
es: 160 gs:   0
> e0000cf8  e0000d40  siogettc (f01790a0,0,0,f02c1730)
> e0000d48  e0000d9c  sioclock (6)
> e0000da4  e0000da8  siopoll  (0,0,0,f0121750)
> e0000db0  e0000df4  clock    (f00d08e0,158,212,0)
>           e0000e0c  clock_in from f00d08e0 in hlted  
>   ax:       0 cx:       0 dx:f01514d8 bx:       0 fl:      212
ds: 160 fs:   0
>   sp:e0000e3c bp:e0000e6c si:       0 di:       0 err:       0
es: 160 gs:   0
> e0000e14  e0000e6c  hlted    (f00cf3ca)
> e0000e74  e0000e78  swtch    (0,0,0,0)
> > q
> [root] cms:/u/crash-101095 > ^D  exit

[ ... ]
> Background info:

>    AST Manhattan SMP (with 2 P60's), 64 megs of ram, 6 gigs
of HD
> space with RAID V, HP 2 gig DAT, Digiboards, 3com EISA


Micros Systems Inc.             Tel: +1 301 210 8000 x2303
12000 Baltimore Ave.            Fax: +1 301 210 6699
Beltsville, MD 20705-1291

1. sco panic with trap 0xE Help needed.

That's hardware - when I had that it was a bad simm - what I did was
remove one simm each day until it stopped panicing. (If it paniced today,
I put that simm back in and took out the next etc).

You need to follow the BTLD instructions in the book that came with the
2940 - you cant just pop it in and turn it on.


2. metroX/redhat 3.0.3: s3/968, #9/771vram, DS64video/vram

3. ULTRA60 keeps crashing with BAD TRAP TYPE - CPU0

4. broken gzip-archiv - HELP ME

5. Solaris 2.x servers crashing with trap type 9

6. Redhat 6.0 hdc2 to hdb2 boot problem

7. Help with crash (BAD TRAP: type=30 rp=2a100ab62e0 addr=1006e0000 mmu_fsr=80100b)

8. RewriteCond and RewriteRule


10. can anyone help: "BAD TRAP", trap type = 0x31

11. Kernel Trap Type E PANICS using gzip -9 on ISC SVR3 ?

12. Linux crashes??? What am I doing wrong?

13. System is crashing if I am using more then one disk on scsi controler :(