Project Home
Project Home
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - SIGSEGV when using layer2 bridge on MPC85xx: (11 Items)
   
SIGSEGV when using layer2 bridge on MPC85xx  
We encounter SIGSEGV in tpass_start_rem() (file tpass.c line171) after approximately 20 minutes runtime.

Our setup is:

MPC8548 with tsec0 and tsec1


io-pkt-v4-hc -t4 -dmpc85xx mac=00e00c000bfe,pci=0 -dmpc85xx mac=00e00c000bff,pci=1,phy=1 rx_delay=0,rx_frame=0,priority=
185 -ptcpip

/sbin/ifconfig tsec0 inet 192.168.101.11 up
/sbin/ifconfig tsec1 inet up
/sbin/ifconfig bridge0 create
/sbin/brconfig bridge0 add tsec0 add tsec1 up

/sbin/ifconfig tsec0 inet alias 192.168.40.16

There is mainly the following traffic on the interfaces

TCP on TSEC0 to/from local processor
TCP via bridge between TSEC0 and TSEC1
UDP on TSEC1 to/from local processor

We are using the QNX 6.4 networking trunk r530 with a modification in sys/main.c to remove the SIGSEGV handler together 
with 6.4 OS from the pre-release. The build for debugging has been done with -g and -O0 option. Adaptive Partitioning is
 also in use.

Because the corefile cannot be loaded into the debugger (for whatever reason ?) we have reproduced the error with io-pkt
-v4-hc running in the Debugger which is connected over serial line. It might be difficult to create a testcase, because 
the current setup uses a bunch of additional HW connected to TSEC1 and a lot of SW running on a PC connected to TSEC0.

Hopefully, you can find the error with the debugger screenshot in the error case. I will send it separately by mail 
because the attachment doesn't work in my environment.

Thanks,
            Guenther


RE: SIGSEGV when using layer2 bridge on MPC85xx  
From: Guenther Weiss 

> Because the corefile cannot be loaded into the debugger

We've been over this before ... you are truncating the
core file.  When I previously reproduced your setup, the
core file produced was larger than the ones you sent us
and loaded correctly into gdb, loaded the .so files, and
showed a very nice backtrace.

Regardless, running it in the debugger should allow you
to do a "bt" (backtrace) and then to print the contents 
of the variables (eg null pointer reference) which caused 
the crash.

--
aboyd
Re: SIGSEGV when using layer2 bridge on MPC85xx  
You have attached gdb to it so you must get the sigsegv, so what is the backtrace and info reg?
gdb>bt
gdb>info r
gdb>info thread
gdb>disass $pc-32 $pc+32
gdb>x/32 $r1-32
Re: SIGSEGV when using layer2 bridge on MPC85xx  
After removing the io-pkt internal SIGSEGV handler und together with the gdb V6.7 from the QNX 6.4 prerelease I'm able 
to load the corefile into the debugger and to get a backtrace.

I have sent the results directly to Sean and Robert because attachments do not work from my PC.

Guenther
Re: SIGSEGV when using layer2 bridge on MPC85xx  
On Thu, Sep 25, 2008 at 06:18:53AM -0400, Guenther Weiss wrote:
> After removing the io-pkt internal SIGSEGV handler und together with the gdb V6.7 from the QNX 6.4 prerelease I'm able
 to load the corefile into the debugger and to get a backtrace.
> 
> I have sent the results directly to Sean and Robert because attachments do not work from my PC.

Please try the latest stuff against your bridging
issue.  See rev 549.

Thanks,

-seanb
Re: SIGSEGV when using layer2 bridge on MPC85xx  
Hi Sean,

Thank you for the bugfix.

Just to give you a short update.

Yesterday, I have updated to r549 and done an incremental build (without make clean) of the non debug version. This io-
pkt-v4-hc did SIGSEGV after 7 hours in the night. I was not sure if the makefile worked correctly and have done a 
complete rebuild (debug version) this morning to get more information in the error case. This stack version worked the 
whole day (10 hours) without SIGSEGV.

Now I don't know if the bug is really fixed or if it does not occur in the debug version.

For this reason, I have done a complete rebuild of the non debug version and let it run over the weekend.

Hopefully, we know more at Monday.

Guenther  
Antwort: Re: SIGSEGV when using layer2 bridge on MPC85xx ("allow zip file")  
Hi Sean,

the io-pkt-v4-hc in no debug version did SIGSEGV after 26 hours of 
operation. The location where the error occured and the backtrace is exact 
the same as with the last try with revision r549 but it is different 
compared to the former corefile before your bugfix. The frequency of 
SIGSEGV occurrence is reduced significantly since your bugfix - but is 
stiil not satisfying.

I will try to get a corefile with the debug version of the stack. But this 
may last, because I can do this only over night and I don't know if the 
error occurs with the debug version at all.

Perhaps you can find the error with the attached corefile without debug 
info.

Guenther






Sean Boudreau <community-noreply@qnx.com> 
25.09.2008 16:41
Bitte antworten an
post14029@community.qnx.com


An
technology-networking <post14029@community.qnx.com>
Kopie

Thema
Re: SIGSEGV when using layer2 bridge on MPC85xx






On Thu, Sep 25, 2008 at 06:18:53AM -0400, Guenther Weiss wrote:
> After removing the io-pkt internal SIGSEGV handler und together with the 
gdb V6.7 from the QNX 6.4 prerelease I'm able to load the corefile into 
the debugger and to get a backtrace.
> 
> I have sent the results directly to Sean and Robert because attachments 
do not work from my PC.

Please try the latest stuff against your bridging
issue.  See rev 549.

Thanks,

-seanb

_______________________________________________
Technology
http://community.qnx.com/sf/go/post14029



+----------------------------------------------------------------------+
| ETAS Mail Security - http://intranet.etasgroup.com/encryption        |
+----------------------------------------------------------------------+
| - The message was not encrypted and not digitally signed             |
+----------------------------------------------------------------------+

Attachment: Compressed file sigsegv_290908.zip 2.19 MB
Re: Antwort: Re: SIGSEGV when using layer2 bridge on MPC85xx ("allow zip file")  
On Mon, Sep 29, 2008 at 12:44:49AM -0400, Guenther Weiss wrote:
> Hi Sean,
> 
> the io-pkt-v4-hc in no debug version did SIGSEGV after 26 hours of 
> operation. The location where the error occured and the backtrace is exact 
> the same as with the last try with revision r549 but it is different 
> compared to the former corefile before your bugfix. The frequency of 
> SIGSEGV occurrence is reduced significantly since your bugfix - but is 
> stiil not satisfying.
> 
> I will try to get a corefile with the debug version of the stack. But this 
> may last, because I can do this only over night and I don't know if the 
> error occurs with the debug version at all.
> 
> Perhaps you can find the error with the attached corefile without debug 
> info.

Also, are you doing any bridge creation / deletion or
marking it up / down?  Is this simply setting up a
bridge and letting it run?

-seanb
Antwort: Re: Antwort: Re: SIGSEGV when using layer2 bridge on MPC85xx ("allow zip file")  
Hi Sean,

this is simply setting up the bridge and letting it run.

Guenther
Re: Antwort: Re: Antwort: Re: SIGSEGV when using layer2 bridge on MPC85xx ("allow zip file")  
Thanks for the testing.

-seanb
Re: Antwort: Re: SIGSEGV when using layer2 bridge on MPC85xx ("allow zip file")  
On Mon, Sep 29, 2008 at 06:43:17AM +0200, Guenther.Weiss@etas.com wrote:
> Hi Sean,
> 
> the io-pkt-v4-hc in no debug version did SIGSEGV after 26 hours of 
> operation. The location where the error occured and the backtrace is exact 
> the same as with the last try with revision r549 but it is different 
> compared to the former corefile before your bugfix. The frequency of 
> SIGSEGV occurrence is reduced significantly since your bugfix - but is 
> stiil not satisfying.
> 
> I will try to get a corefile with the debug version of the stack. But this 
> may last, because I can do this only over night and I don't know if the 
> error occurs with the debug version at all.
> 
> Perhaps you can find the error with the attached corefile without debug 
> info.
> 
> Guenther

Please try the latest.  For your debug variant
try just -g and not -O0.  If there's still an
issue it may show up more easily if the optimization
level is the default:

# make DEBUG=-g

-seanb