All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dennis Gilmore <dgilmore@redhat.com>
To: sparclinux@vger.kernel.org
Subject: opps building sparc64 packages
Date: Fri, 02 Jan 2009 20:35:19 +0000	[thread overview]
Message-ID: <200901021435.23972.dgilmore@redhat.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 4303 bytes --]

trying to build openbabel sparc64 
https://sparc.koji.fedoraproject.org/koji/taskinfo?taskID=112540  I got an 
opps 

sun4v_data_access_exception: ADDR[ffffb83000000008] CTX[16ba] TYPE[0009], going.                                                                              
              \|/ ____ \|/                                                                                                                                    
              "@'/ .. \`@"                                                                                                                                    
              /_| \__/ |_\                                                                                                                                    
                 \__U_/                                                                                                                                       
lt-atom(22311): Dax [#1]                                                                                                                                      
TSTATE: 0000009911001600 TPC: 00000000004821d8 TNPC: 00000000004821dc Y: 
00000000    Not tainted                                                              
TPC: <exit_robust_list+0x78/0x10c>                                                                                                                            
g0: 0000000000000064 g1: 0000000000000000 g2: fff8b83000000008 g3: 
00000000000004ac                                                                           
g4: fffff803e10e9740 g5: fffff803ff392000 g6: fffff8038a094000 g7: 0000000000000001                                                                           
o0: 00000014000014a4 o1: 000007fefff9d718 o2: 000007fefff9d728 o3: 
0000000000000000                                                                           
o4: 0000000000000000 o5: 0000000000000001 sp: fffff8038a097441 ret_pc: 
00000000004666c8                                                                       
RPC: <do_group_exit+0x8c/0xc4>                                                                                                                                
l0: fffff803e10e9740 l1: 0000000000000800 l2: 00000014000014a4 l3: 
fffff80100612790                                                                           
l4: 0000000000000000 l5: 0000000000000000 l6: fffff8038a097cf8 l7: 
0000000000466700                                                                           
i0: fffff803e10e9740 i1: 0000000000000001 i2: 0000000000000001 i3: 
0000000000000000                                                                           
i4: 0000000000000000 i5: 0000000000000001 i6: fffff8038a097511 i7: 
0000000000465f64                                                                           
I7: <do_exit+0x1d0/0x8a8>                                                                                                                                     
Caller[0000000000465f64]: do_exit+0x1d0/0x8a8                                                                                                                 
Caller[00000000004666c8]: do_group_exit+0x8c/0xc4                                                                                                             
Caller[00000000004062d4]: linux_sparc_syscall+0x34/0x44                                                                                                       
Caller[fffff80100a9203c]: 0xfffff80100a9203c                                                                                                                  
Instruction DUMP: a8102000  1068001d  ac07a7e7 <c6d8a000> 82100000  a0103ff2  
80a06000  90008015  92100018                                                    
Fixing recursive fault but reboot is needed!       


Ive seen something similar building OOo also 
22311 ?        D      0:00 /builddir/build/BUILD/openbabel-2.2.0b3-20080215-
r2249/test/.libs/lt-atom

the process that should be running ends up in a D state  so it is sleeping and 
unkillable.  the processes hang around until a reboot.  any ideas where I 
should start looking?  this happens on a T1000 and T2000 i've not yet tried on 
non-niagara hardware.  

Dennis

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

             reply	other threads:[~2009-01-02 20:35 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-01-02 20:35 Dennis Gilmore [this message]
2009-01-20  6:35 ` opps building sparc64 packages David Miller
2009-01-20  6:52 ` David Miller
2009-01-23 17:31 ` Dennis Gilmore
2009-01-24  3:50 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200901021435.23972.dgilmore@redhat.com \
    --to=dgilmore@redhat.com \
    --cc=sparclinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.