Project Home
Project Home		 Wiki
Wiki		 Discussion Forums
Discussions		 Project Information
Project Info
Networking/Discussion/Networking Drivers/6.3.2 io-net cores/List of Posts
Forum Topic - 6.3.2 io-net cores: (5 Items)
   
Update
Robert D'Attilio(deleted)
08/10/2009 2:34 PM
post35603
6.3.2 io-net cores   
Hi:

Every now and then we get instances of io-net coreing. Running it through gdb gives the following information:

Program terminated with signal 4, Illegal instruction.
#0  0xfe39bffc in arpintr1 ()
   from /opt/qnx632/target/qnx6/ppcbe/lib/dll/npm-tcpip-v4.so

Anyone know if this is a 'known' issue.

thanks
robert
Andrew Boyd(deleted)
08/10/2009 2:46 PM
post35605
RE: 6.3.2 io-net cores   
A new one on me.

I would disassemble the code around 0xfe39bffc to see
if it looks sensible.  While you're at it, print a
screen dump of it and compare it to a disassembly
of what it npm-tcpip-v4.so should be ie before the dump.

If you're getting corrupted memory, that's an 
interesting problem.  Often on some boards it
goes away when you disable the highest-level
cache (L3 or L2).

--
aboyd
Robert D'Attilio(deleted)
08/10/2009 3:17 PM
post35616
RE: 6.3.2 io-net cores   
Andrew:

I tried your suggestion and from the gdb session on the corefile tried
to disassemble around the offending address but get the following:

(gdb) disassem  0xfe39bffc
Dump of assembler code for function arpintr1:
0xfe39bf74 <arpintr1+0>:        Cannot access memory at address
0xfe39bf74


Fine. Continuing on, I did an objdump -d on the executable but I end up
with a dump of the entire .text section list with no function names (I
guess 'cause it was stripped). Also the memory addresses are offsets,
any idea of how to determine the actual load address of the library?

thanks

-----Original Message-----
From: Andrew Boyd [mailto:community-noreply@qnx.com] 
Sent: Monday, August 10, 2009 2:47 PM
To: drivers-networking
Subject: RE: 6.3.2 io-net cores


A new one on me.

I would disassemble the code around 0xfe39bffc to see
if it looks sensible.  While you're at it, print a
screen dump of it and compare it to a disassembly
of what it npm-tcpip-v4.so should be ie before the dump.

If you're getting corrupted memory, that's an 
interesting problem.  Often on some boards it
goes away when you disable the highest-level
cache (L3 or L2).

--
aboyd




_______________________________________________

Networking Drivers
http://community.qnx.com/sf/go/post35605
Andrew Boyd(deleted)
08/10/2009 3:44 PM
post35622
RE: 6.3.2 io-net cores   
> Cannot access memory at address 0xfe39bf74

Argh.  Sometimes it can be hard to tell exactly
what's going on with the tools - sometimes dumper 
and gdb don't always do the right thing, and our 
long-suffering tools people - who pretty much run 
away when they see me now - have fixed a lot of stuff 
like this, esp for non-x86 cpus.

Anyways, if it didn't capture the offending
memory, I'm not sure what you can do.  Is it
possible the core is getting truncated somehow
by dumper?  I think it has a command line option
to do that, which you don't want.  Also, you can 
sometimes be limited by memory available for 
/dev/shmem if that's where the core is going.

--
aboyd
Mario Charest
08/10/2009 4:07 PM
post35625
RE: 6.3.2 io-net cores   

> -----Original Message-----
> From: Andrew Boyd [mailto:community-noreply@qnx.com]
> Sent: Monday, August 10, 2009 3:44 PM
> To: drivers-networking
> Subject: RE: 6.3.2 io-net cores
> 
> > Cannot access memory at address 0xfe39bf74
> 
> Argh.  Sometimes it can be hard to tell exactly
> what's going on with the tools - sometimes dumper
> and gdb don't always do the right thing, and our
> long-suffering tools people - who pretty much run
> away when they see me now - 

Try dressing up as a green girl.  That could change their minds.

> 
> Anyways, if it didn't capture the offending
> memory, I'm not sure what you can do.  Is it
> possible the core is getting truncated somehow
> by dumper?  I think it has a command line option
> to do that, which you don't want.  Also, you can
> sometimes be limited by memory available for
> /dev/shmem if that's where the core is going.
> 
> --
> aboyd
> 
> 
> 
> 
> _______________________________________________
> 
> Networking Drivers
> http://community.qnx.com/sf/go/post35622
>

Return


  A subsidiary of BlackBerry             All content ©2004-2013, QNX Software Systems