[Fwd: Re: Help with crash (BAD TRAP: type=30 rp=2a100ab62e0

This is a multi-part message in MIME format.

--Boundary_(ID_ev9be2WnU9iE43X0trXmxQ)
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT

Hi guyz,

A follow up to my mail from yesterday and a reply from a Gavin Maltby
confirms that this was caused by IPF.


-Bruno

--Boundary_(ID_ev9be2WnU9iE43X0trXmxQ)
Content-type: message/rfc822;
name="Re: Help with crash (BAD TRAP: type=30 rp=2a100ab62e0 addr=1006e0000
mmu_fsr=80100b)"
Content-disposition: inline;
filename="Re: Help with crash (BAD TRAP: type=30 rp=2a100ab62e0 addr=1006e0000
mmu_fsr=80100b)"

Path:
pd7tw3no!pd7cy1no!shaw.ca!border1.nntp.dca.giganew s.com!nntp.giganews.com!newsfeed-east.nntpserver.com!nntpserver.com!newsfeed1.sea.p nap.net!newsfeed2.sea.pnap.net!newsfeed.pnap.net!b rmea-news-1.sun.com!news1nwk.sfbay.sun.com!new-usenet.uk.sun.com!not-for-mail
X-Trace: new-usenet.uk.sun.com 1091097749 9739 129.156.96.92
(29 Jul 2004 10:42:29 GMT)
Date: Thu, 29 Jul 2004 11:43:17 +0100
From: Gavin Maltby <G_a_v_i_n.M_a_l_t_b_y@sun.com>
Subject: Re: Help with crash (BAD TRAP: type=30 rp=2a100ab62e0 addr=1006e0000
mmu_fsr=80100b)
In-reply-to: <vcZNc.127058$Mr4.50086@pd7tw1no>
Message-id: <ceakal$9gb$1@new-usenet.uk.sun.com>
Organization: Sun Microsystems
X-Complaints-to: usenet@new-usenet.uk.sun.com
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii; format=flowed
Content-transfer-encoding: 7BIT
NNTP-posting-date: 29 Jul 2004 10:42:29 GMT
X-Accept-Language: en-us, en
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7a) Gecko/20040114
X-Received-Date: Thu, 29 Jul 2004 04:50:59 MDT (pd7tw3no)
Newsgroups: comp.unix.solaris
NNTP-posting-host: vpn-129-156-96-92.emea.sun.com
References: <vcZNc.127058$Mr4.50086@pd7tw1no>
Xref: pd7hu0no comp.unix.solaris:25514

Bruno Saverio Delbono wrote:
[cut]
> -- trap data type: 0x30 (data access exception) rp: 0x2a100ab62e0 --
> addr: 0x1006e0000
> mmu_sfsr: fault type: 0x20 - VA out of range (D/I-MMU branch, CALL,
> sequential)

This likely means that something has tried to access the hole in the
VA range that UltraSPARC-II chips have; they only have an effective
44 bit VA range, with a big hole in the middle of the full 64 bit
VA range. The MMU will police any attempts to address the hole,
taking a data access exception trap indicating VA out of range in
the fault type. Addresses 0x000008FFFFFFFFFF - 0xFFFFF7FFFFFFFFFF
constitute the VA hole.

Note that the fault address 0x1006e0000 does not
look all that illegal at first glance, but that this is not the
exact VA that was accessed. The DMMU fault address register
is a 64-bit field derived from sign-extending bit 43, so
bits <63:44> do not correspond to the VA actually used.

> %asi:0x80 ASI_P valid:1 priv:1 write:0 overwrite:1
> context:IMMU:Pri,DMMU:Pri nofault:0 TLB miss:0 side-effect:0
> pc: 0x780b7a60 ipf:fr_scanlist+0xb8: ldx [%i5 + 0x18], %l3

We're loading from %i5 + 0x18. The frame below shows us that
at time of trap %i5 was 0x81800001006e0068, and so that + 0x18
is certainly in the VA hole (and if you lop off the upper bits
and round to a 8K page boundary you get the fault address of
0x1006e0000).

Now disassemble ipf:fr_scanlist to work out what it was using
%i5 for, and compare with source. It looks like this
may have been the current list element pointer, and some
next element pointer may have directed us into the weeds.
Reasonably like to be a fault in ipf, and certainly nothing
to do with your userland dns stuff.

> npc: 0x780b7a64 ipf:fr_scanlist+0xbc: subcc %l3, %g0, %g0 ( cmp
> %l3, %g0 )
> global: %g1 0x3
> %g2 0x1 %g3 0x1388
> %g4 0 %g5 0x300323800ac
> %g6 0 %g7 0x30000ddc2a0
> out: %o0 0x2098 %o1 0x1
> %o2 0x2097 %o3 0x2097
> %o4 0x8 %o5 0x8
> %sp 0x2a100ab5b81 %o7 0x780b8230
> loc: %l0 0 %l1 0x30000070cb0
> %l2 0x7808f9b8 %l3 0x410607d700045648
> %l4 0x2a100ab66bc %l5 0x15
> %l6 0x4 %l7 0x15
> in: %i0 0x1 %i1 0x2a100ab66a8
> %i2 0x30001f9258c %i3 0x30001f92560
> %i4 0x2a100ab66a8 %i5 0x81800001006e0068
> %fp 0x2a100ab5d91 %i7 0x780b89bc
> <trap>ipf:fr_scanlist+0xb8 (0x1, 0x2a100ab66a8, 0x30001f9258c,
> 0x30001f92560, 0x2a100ab66a8, 0x81800001006e0068)
> ipf:fr_check+0x5f4 (0x30032380098, 0x30000c10680, 0x0, 0x1, 0x202,
> 0x2a100ab66a0)
> ipf:fr_precheck+0xba0 (0x2a100ab6b10, 0x1c, 0xe, 0x30032380098,
> 0x30000c10680, 0x30000c10680)
> ipf:fr_qout+0x40c (0x30000be6618, 0x30000c10680, 0x20, 0x2a100197d40,
> 0x26844a72, 0x300304b76c8)
> unix:putnext+0x21c (0x0, 0x30000c10680, 0x0, 0x8004500, 0x800,
> 0x24294ee0800)
> ip:ip_wput_ire+0xacc (0x10000, 0x30000070cb0, 0x3, 0xffff, 0x1855bf1c,
> 0x30000c10680)
> ip:ire_send+0x18c (0x30014bc9e08, 0x30000c10680, 0x30030e36a30, 0x2,
> 0x0, 0x30014bb7680)
> ip:ire_add_then_send+0x244 (0x30000a037a0, 0x0, 0x30000c10680, 0x1,
> 0x30000ddc2a4, 0x30000ddc29c)
> ip:ip_newroute+0x9bc (0x30000c10680, 0x10, 0x0, 0x14ad000, 0x10000,
> 0x3000023dd78)
> ip:ip_wput - frame recycled
> ipf:ipf_ip_qin+0x98 (0x30014bc9e08, 0x30000c10680, 0x20, 0x8, 0x0, 0x7)
> unix:putnext+0x21c (0x0, 0x30000833f80, 0x20, 0x0, 0x1, 0x0)
> udp:udp_wput+0x5b0 (0x34, 0x14, 0x34, 0x300323800ac, 0x30032380098, 0x45)
> unix:putnext+0x21c (0x0, 0x30014bb7680, 0x20, 0x30000c10680, 0x0, 0x45)
> genunix:strput+0x270 (0x30002aa8d58, 0x0, 0x0, 0x2a100ab7698, 0x0, 0x0)
> genunix:kstrputmsg+0x36c (0x30032377d18, 0x3003236e128, 0x0, 0x0, 0x0, 0x0)
> sockfs:sosend_dgram+0x25c (0x0, 0x300030e3998, 0x10, 0x2a100ab7a00, 0x8,
> 0x0)
> sockfs:sosendmsg+0x3f4 (0x0, 0x0, 0x6, 0x20, 0x1, 0x0)
> sockfs:sendit+0x15c (0x2a100ab7a00, 0x8, 0x30032377d18, 0x8, 0x0, 0x7)
> sockfs:send+0x74 (0x0, 0x16a30a, 0x2c, 0x0, 0x0, 0x0)
> sockfs:send32+0x34 (0x0, 0x16a30a, 0x2c, 0x0, 0x0, 0x45)
> unix:syscall_trap32+0xa8 (0x0, 0x16a30a, 0x2c, 0x0, 0x0, 0x45)
> -- switch to user thread's user stack --

Gavin

--Boundary_(ID_ev9be2WnU9iE43X0trXmxQ)--