[uClinux-dev] Signals sometimes not delivered (m68knommu)?

John B Moore JMoore at moreycorp.com
Thu Feb 26 14:33:24 EST 2009


When I look in /proc/<pid>/status I can see that in the cases where the 
control-c does not work, most signals are blocked. Normally signals look 
like:

SigPnd: 0000000000000000
ShdPnd:0000000000000000
SigBlk: 0000000080000000
SigIgn: 0000000000000001
SigCgt: 0000000380000000
CapInh: 0000000000000000

 but in the case when control-c fails I see :

SigPnd: 0000000000000000
ShdPnd:0000000000000000
SigBlk: 01e847a881d8f42a
SigIgn: 0000000000000001
SigCgt: 0000000380000000
CapInh: 0000000000000000

I have searched around and cant seem to find any code obvious that is 
doing this. Any suggestions on where I shoudl be looking?

Thank You,

John Moore
The Morey Corporation
100 Morey Drive
Woodridge, IL 60517-8135
Office Phone: (630) 754-2305
Email: jmoore at moreycorp.com




Mike Frysinger <vapier at gentoo.org> 
Sent by: uclinux-dev-bounces at uclinux.org
02/25/2009 05:08 PM
Please respond to
uClinux development list <uclinux-dev at uclinux.org>


To
uclinux-dev at uclinux.org
cc
John B Moore <JMoore at moreycorp.com>
Subject
Re: [uClinux-dev] Signals sometimes not delivered (m68knommu)?






On Wednesday 25 February 2009 18:00:30 John B Moore wrote:
> I am working with a device which uses an M523x coldfire running
> uClinux-dist-20080808 with the 20090112 patch applied as well (kernel
> 2.6.26-uc0). I am using uClibc 9.30 and the compiler is gcc 4.2.3 
uclinux
> cross compiler. I am connecting to the device using PPP over a serial 
link
> via telnet (non-busybox telnet) which runs the busybox msh. The problem 
I
> am having is after using control-c once or twice to interrupt 
applications
> in that session, control-c does not work anymore for most applications
> (although "top" always gets the interrupt from control-c for some 
reason).
> In most applications it will then just print ^C and ignore the request 
as
> if the intr character is not set or as if there was no controlling tty.
>
> I have tried other shells and busybox telnetd as well and the problem
> still exists. If I try to issue a "kill -INT pid" from another telnet
> session, the signal is ignored, but if I issues "kill -TERM pid" the
> applicaiton terminates properly. Note also that this problem does not
> occur on an older version of uClinux from earlier stages of the project,
> which uses a 2.6.17 kernel and uClibc 9.26 with a 4.1.1 compiler, so I
> know the device is functioning properly, but I need to upgrade.

might want to look at /proc/<pid>/status and see if the Sig fields look 
sane
-mike
_______________________________________________
uClinux-dev mailing list
uClinux-dev at uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev at uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev






This e-mail, including attachments, may contain information that is 
confidential and/or proprietary, and may only be used by the person to 
whom this email is addressed. If the recipient of this e-mail is not the 
intended recipient or an authorized agent, the reader is hereby notified 
that any dissemination, distribution, or copying of this e-mail is 
prohibited. If this e-mail has been delivered to you in error, please 
notify the sender by replying to this message and deleting this e-mail 
immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.uclinux.org/pipermail/uclinux-dev/attachments/20090226/836329fe/attachment.html>


More information about the uClinux-dev mailing list