AF:
NF:0
PS:10
SRH:1
SFN:
DSR:
MID:
CFG:
PT:0
S:andy.sharp@lsi.com
RQ:
SSV:mhbs.lsil.com
NSV:
SSH:
R:<Maxim.Kozlovsky@lsi.com>
MAID:2
X-Sylpheed-Privacy-System:
X-Sylpheed-Sign:0
SCF:#mh/Mailbox/sent
RMID:#imap/LSI/INBOX	0	861DA0537719934884B3D30A2666FECC010E3D2086@cosmail02.lsi.com
X-Sylpheed-End-Special-Headers: 1
Date: Mon, 22 Mar 2010 17:21:10 -0700
From: Andrew Sharp <andy.sharp@lsi.com>
To: "Kozlovsky, Maxim" <Maxim.Kozlovsky@lsi.com>
Subject: Re: kernel stacktrace
Message-ID: <20100322172110.0550c53c@ripper.onstor.net>
In-Reply-To: <861DA0537719934884B3D30A2666FECC010E3D2086@cosmail02.lsi.com>
References: <861DA0537719934884B3D30A2666FECC010E3D2043@cosmail02.lsi.com>
	<20100322145532.6950acfa@ripper.onstor.net>
	<861DA0537719934884B3D30A2666FECC010E3D2086@cosmail02.lsi.com>
Organization: LSI
X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; x86_64-pc-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Mon, 22 Mar 2010 17:01:17 -0600 "Kozlovsky, Maxim"
<Maxim.Kozlovsky@lsi.com> wrote:

> Any ideas besides "your stack is hosed"? 
> 
> 
> Here is another bad stack trace, after modifying the
> code/sm-tests/sm-test.c to crash in mytest_create():
> 
>         ...
> Call Trace:
> [<ffffffffc03d10c0>] $LVL8+0x0/0x10 [sm_test]
> [<ffffffffc03d10c0>] $LVL8+0x0/0x10 [sm_test]

C'mon, that doesn't look hosed to you?  I don't know the full context
of what you're up to, but it looks like you're mucking about in the
esm_threads stuff.  Could be hosing the stack.  Anyway, this example
does a page fault right away, and the stack trace looks suspiciosly
like the other one, suggesting it is crashing somewhat immediately as
well.


> int32
> mytest_create(esm_handle_t handle, int32	next_state,
> esm_event_t	this_event, void *user_info)
> {
>     printk("%s:\n", __func__);
>     *(int *)0 = 0;
>     return next_state;
> }
> 
> Clearly the stack is not hosed here. Full output below:
> 
> modprobe sm-test
> neteee2: module license 'unspecified' taints kernel.
> eee_init: ENTRY
> eee_initIPCQueues: ENTRY my_index 0
> eee_initIPCQueues: EXIT; num_ipc_queues 6
> eee_initFixedFwdQueues: Initialize eee.rcv_queue[]
> eee_initFixedFwdQueues: EXIT
> eee_initFWDQueues: Initialize eee.fwd_queue[]
> eee_initFwdQueues() eee.fwd_queue[0] fwd_start 0xa8000001ffa8f950,
> end 0xa8000001ffa8fa50 eee_initFwdQueues() eee.fwd_queue[0] fwd_head
> 0xa8000001ffa8f950, tail 0xa8000001ff1c3a78 eee_initFwdQueues()
> eee.fwd_queue[1] fwd_start 0xa8000001fe873000, end 0xa8000001fe874000
> eee_initFwdQueues() eee.fwd_queue[1] fwd_head 0xa8000001fe873000,
> tail 0xa8000001ff1c3f48 eee_initFwdQueues() eee.fwd_queue[2]
> fwd_start 0xa8000001fdd52000, end 0xa8000001fdd53000
> eee_initFwdQueues() eee.fwd_queue[2] fwd_head 0xa8000001fdd52000,
> tail 0xa8000001ff1c3960 eee_initFWDQueues EXIT eee_app_init:
> ENTRY/EXIT eee_thread: enter eee_init: EXIT
> eee_thread: enter
> mytest_create:
> CPU 2 Unable to handle kernel paging request at virtual address
> 0000000000000000, epc == ffffffffc03d10c0, ra == ffffffffc03d10c0
> Oops[#1]: Cpu 2
> $ 0   : 0000000000000000 0000000010001fe0 0000000000000012
> 0000000000000000 $ 4   : ffffffff832f2a60 0000000010001fe0
> 0000000000020000 a8000001ffab2d40 $ 8   : ffffffff832f2a68
> 0000000000000027 0000000000000001 0000000000000080 $12   :
> 00000000000008fc a8000000870c2000 ffffffff83330000 a8000001ff478000
> $16   : 0000000000000000 ffffffffc03d0000 ffffffffc03d7b18
> 0000000000000001 $20   : 0000000000000000 ffffffffc03d7b08
> ffffffffc03d7e20 c000000000000000 $24   : 0000000000000001
> a8000001ff280000 $28   : a8000001ff478000 a8000001ff47bca0
> ffffffff83050190 ffffffffc03d10c0 Hi    : 00000000000000a0 Lo    :
> 00000000000000be epc   : ffffffffc03d10c0 $LVL8+0x0/0x10
> [sm_test]     Tainted: P ra    : ffffffffc03d10c0 $LVL8+0x0/0x10
> [sm_test] Status: 10001fe3    KX SX UX KERNEL EXL IE 
> Cause : 1080800c
> BadVA : 0000000000000000
> PrId  : 05041100
> Modules linked in: sm_test(P) esm_threads(P) elog_mod(P) neteee2(P)
> ipv6 Process modprobe (pid: 1075, threadinfo=a8000001ff478000,
> task=a80000000b15edc0) Stack : 0000000000000000 0000000000000000
> 0000000000000000 0000000000000000 a8000001fd36a758 ffffffffc03b3fb0
> 0000000000000000 0000000000000020 0000000000000000 0000000000000000
> 0000000000000000 a8000001ff47bd40 ffffffffc02e1398 ffffffffc03d1630
> a8000001fee43640 0000000000000021 0000000000000021 ffffffffc03d7b60
> c000000000006878 ffffffffc03d11b4 ffffffffc03d7b60 ffffffff832f0000
> ffffffff83051b14 ffffffff83053020 ffffffffc02ece38 ffffffffc03533a0
> c000000000006748 0000000000000007 0000000000000000 0000000000000345
> 0000000000000345 0000000000000000 0000000000000006 c000000000007078
> c000000000006af8 c000000000007038 0000000000000000 a8000001ff1c3d18
> c0000000000112d0 000000000000001f ...
> Call Trace:
> [<ffffffffc03d10c0>] $LVL8+0x0/0x10 [sm_test]
> [<ffffffffc03d10c0>] $LVL8+0x0/0x10 [sm_test]
> 
> 
> Code: ffa70008  0040f809  ffa80010 <ac000000> 0200102d  dfbf0028
> dfb00020  03e00008  67bd0030 Crashdump saved to prom
> Segmentation fault
> tuxrx0:~#
> 
> 
> -----Original Message-----
> From: Kozlovsky, Maxim 
> Sent: Monday, March 22, 2010 2:56 PM
> To: Sharp, Andy
> Subject: RE: kernel stacktrace
> 
> 
> 
> -----Original Message-----
> From: Andrew Sharp [mailto:andy.sharp@lsi.com] 
> Sent: Monday, March 22, 2010 2:56 PM
> To: Kozlovsky, Maxim
> Subject: Re: kernel stacktrace
> 
> On Mon, 22 Mar 2010 15:49:16 -0600 "Kozlovsky, Maxim"
> <Maxim.Kozlovsky@lsi.com> wrote:
> 
> > Hello,
> > 
> > Why I am getting so uninformative stack trace from kernel crash?
> > 
> > Call Trace:
> > [<ffffffffc0bba578>] $LVL86+0x8/0x10 [scsi_mod]
> > [<ffffffffc0bba568>] $LVL85+0x0/0x8 [scsi_mod]
> > 
> > Is there something I can do to make it better?
> > 
> > Max
> > 
> 
> Normally you shouldn't get such a short stack trace, hence I would say
> your stack is hosed. 
> 
> [MK] 
> The stack is not hosed. 
