|
|
Re: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/13/2008 3:28 PM
post16533
|
Re: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
It was requested that I post a kernel event trace so here it is. This is the trace from the session mentioned above
where characters were typed at the host PC, received by devc-serpxa250 and never sent to sh which is running in a
partition that was budgeted 10% of cpu IIRC.
|
|
|
|
|
|
|
Re: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/14/2008 8:46 AM
post16577
|
Re: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
> It was requested that I post a kernel event trace so here it is. This is the
> trace from the session mentioned above where characters were typed at the host
> PC, received by devc-serpxa250 and never sent to sh which is running in a
> partition that was budgeted 10% of cpu IIRC.
Is the shell in question that with pid 426014 ?
Following is my view about what happened:
shell is receive blocked.
The uart indicates your devc-ser that data is there.
IntrHandler is invoked event is returned and delivered to devc-ser..
Event, Time, Owner, Type, Data
160144, 4s 883ms 976us, Interrupt 0x16, Entry, interrupt 0x16 ip 0x10e830
160149, 4s 884ms 29us, Interrupt 0x16 devc-serpxa250, Handler Entry, \
pid 3 interrupt 0x16 ip 0x1022f8 area 0x11d010 process devc-serpxa250
160150, 4s 884ms 68us, Interrupt 0x16 devc-serpxa250, Sigevent Pulse,\
scoid 0x40000003 pid 3 process devc-serpxa250
160151, 4s 884ms 83us, devc-serpxa250 Thread 1, Ready, pid 3 tid 1
160152, 4s 884ms 91us, Interrupt 0x16 devc-serpxa250, Handler Exit,\
interrupt 0x16 sigev_notify 4
Event, Time, Owner, Type, Data
160153, 4s 884ms 98us, Interrupt 0x16, Exit, interrupt 0x16 flags 0x1
..
..
..
Event, Time, Owner, Type, Data
160247, 4s 885ms 825us, devc-serpxa250 Thread 1, Receive Pulse, scoid \
0x40000003 pid 3 process devc-serpxa250
...
...
...
...
...
Event, Time, Owner, Type, Data
161064, 4s 902ms 277us, devc-serpxa250 Thread 1, Running, pid 3 tid 1
161065, 4s 902ms 289us, devc-serpxa250 Thread 1, MsgReplyv Enter, \ rcvid 0x7 status 0x1
161070, 4s 902ms 373us, devc-serpxa250 Thread 1, Reply, tid 1 pid 426014 process sh
161071, 4s 902ms 386us, sh Thread 1, Ready, pid 426014 tid 1
Then Communication between those both goes ahead sh writes something ....devc replies and then sh forks
something and goes to sigsuspend probably waiting for some child to exit ?
For me it is interresting why Your shell is going to sigsupend blocked state....??
For whom is it waiting for ?
I do not see that this has at all some thing to do with APS etc..
Perhaps somebody else sees more and more clear...
Jeevan
|
|
|
|
|
|
|
Re: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/14/2008 11:41 AM
post16586
|
Re: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
[...]
>
> Then Communication between those both goes ahead sh writes something ....devc
> replies and then sh forks
> something and goes to sigsuspend probably waiting for some child to exit ?
>
> For me it is interresting why Your shell is going to sigsupend blocked state..
> ..??
>
> For whom is it waiting for ?
>
> I do not see that this has at all some thing to do with APS etc..
The sigsuspend is not important, what you observed is how the application works. There is one serial port. It is one of
three available interface ports (serial, gpib, usb) that can be used from a host PC to our unit. The host PC normally
sends SCPI commands to our unit for handling by a communication process.
We needed a backdoor way to take over the serial port for debug purposes. When a special command is sent a process is
spawned to take over the serial port, spawns a child shell that inherits the serial port fds, and goes into sigsuspend
waiting for the child shell to exit. At this point any commands sent over the serial port are directed to the child
shell. If 'exit' is sent then the child shell exits, the sigsuspend cleans up, and command is returned to the normal
SCPI command parser.
It's simply a way to take over the serial port for debug.
The APS problem occurs *after* the child shell is up and running. If the system is loaded, and a command is sent over
the serial port to the child shell, *that* command is not executed due to lack of CPU cycles. It works fine on an
unloaded system, it fails on a heavily loaded system.
If this is too confusing I can go back to using telnet which has the same problem. Shell commands issued to a telnet
shell don't work either when the system is loaded even though all inetd/telnetd/sh related processes are in their own AP
partition with a 10% budget. In fact, any existing telnet shell with become unresponsive when the system is loaded, and
eventually the host will disconnect.
The serial case seemed simpler since it didn't have as many processes and config/password files to handle.
|
|
|
|
|
|
|
AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/14/2008 2:40 PM
post16603
|
AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
Hi Ken,
can you provide a trace done with wide mode tracing (-w)?
Would be good to see more details on the pulse object that is send at event 160150
At which time/point do you initialize your pulse object?
If you use SIGEV_PULSE_PRIO_INHERIT, then the pulse gets' the process' initial priority information when sending the
pulse, not the one the thread had when you created the pulse object (check nano_event.c).
So maybe your IR handler is running in a different partition when the pulse is registered for the ISR.
Checking nano_event.c .... I guess that you should use PULSE_DELIVER_APS_CRITICAL_FLAG
For your pulse object your registring on the ISR.
Any comments from you QNX guys?
/hp
-----Ursprüngliche Nachricht-----
Von: Ken Schumm [mailto:community-noreply@qnx.com]
Gesendet: Fr 14.11.2008 17:41
An: ostech-core_os
Cc:
Betreff: Re: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
[...]
>
> Then Communication between those both goes ahead sh writes something ....devc
> replies and then sh forks
> something and goes to sigsuspend probably waiting for some child to exit ?
>
> For me it is interresting why Your shell is going to sigsupend blocked state..
> ..??
>
> For whom is it waiting for ?
>
> I do not see that this has at all some thing to do with APS etc..
The sigsuspend is not important, what you observed is how the application works. There is one serial port. It is one of
three available interface ports (serial, gpib, usb) that can be used from a host PC to our unit. The host PC normally
sends SCPI commands to our unit for handling by a communication process.
We needed a backdoor way to take over the serial port for debug purposes. When a special command is sent a process is
spawned to take over the serial port, spawns a child shell that inherits the serial port fds, and goes into sigsuspend
waiting for the child shell to exit. At this point any commands sent over the serial port are directed to the child
shell. If 'exit' is sent then the child shell exits, the sigsuspend cleans up, and command is returned to the normal
SCPI command parser.
It's simply a way to take over the serial port for debug.
The APS problem occurs *after* the child shell is up and running. If the system is loaded, and a command is sent over
the serial port to the child shell, *that* command is not executed due to lack of CPU cycles. It works fine on an
unloaded system, it fails on a heavily loaded system.
If this is too confusing I can go back to using telnet which has the same problem. Shell commands issued to a telnet
shell don't work either when the system is loaded even though all inetd/telnetd/sh related processes are in their own AP
partition with a 10% budget. In fact, any existing telnet shell with become unresponsive when the system is loaded, and
eventually the host will disconnect.
The serial case seemed simpler since it didn't have as many processes and config/password files to handle.
_______________________________________________
OSTech
http://community.qnx.com/sf/go/post16586
*******************************************
Harman Becker Automotive Systems GmbH
Management Board: Dr. Klaus Blickle (Chairman), Dr. Udo Hüls, Michael Mauser, Regis Baudot
Chairman of the Supervisory Board: Ansgar Rempp | Domicile: Karlsbad |
Local Court Mannheim: Register No. 361395
*******************************************
Diese E-Mail enthaelt vertrauliche und/oder rechtlich geschuetzte Informationen. Wenn Sie nicht der richtige Adressat
sind oder diese E-Mail irrtuemlich erhalten haben, informieren Sie bitte sofort den Absender und loeschen Sie diese Mail
. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet.
This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have
received this e-mail in error) please notify the sender immediately and...
View Full Message
|
|
|
|
|
|
|
Re: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/14/2008 3:01 PM
post16604
|
Re: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
I'm off today but will capture a wide trace next week.
All I'm trying to do is set up a 10% budget partition that we can login to to run QNX utilities like pidin, sloginfo,
etc.
In the telnet case there is not a single piece of our code running in the AP partition and any call to a QNX driver
(disk, character) fails when the system is loaded. Telnet cannot even maintain a connection when the system is loaded
and it is in the 10% partition.
It could be a high interrupt load but that wouldn't explain why other components of ours continue to work (GUI refreshes
and is responsive, the SCPI host commands all work, writing to flash works, etc).
|
|
|
|
|
|
|
Re: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/17/2008 10:37 AM
post16675
|
Re: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
I ran another test today and captured a wide event trace log (attached).
A pidin sched prior to the test shows this:
------------------------------------------------------------------------------------------------------
pid tid name prio cpu ExtSched STATE
1 1 procnto 0f 0 System READY
1 2 procnto 10r 0 System RECEIVE
1 3 procnto 10r 0 System RECEIVE
1 4 procnto 10r 0 System RECEIVE
1 5 procnto 10r 0 System RECEIVE
1 6 procnto 10r 0 System RECEIVE
1 7 procnto 10r 0 System RECEIVE
1 8 procnto 10r 0 System RECEIVE
1 9 procnto 10r 0 System RECEIVE
1 10 procnto 10r 0 DevDebug RUNNING
1 11 procnto 10r 0 System RECEIVE
2 1 ot/devf-dbpxa270dp 10r 0 System SIGWAITINFO
2 2 ot/devf-dbpxa270dp 10r 0 System RECEIVE
2 3 ot/devf-dbpxa270dp 30r 0 System RECEIVE
2 4 ot/devf-dbpxa270dp 10r 0 System RECEIVE
2 5 ot/devf-dbpxa270dp 10r 0 System RECEIVE
3 1 oot/devc-serpxa250 24r 0 System RECEIVE
4 1 proc/boot/slogger 30r 0 System RECEIVE
5 1 proc/boot/pipe 10r 0 System SIGWAITINFO
5 2 proc/boot/pipe 10r 0 System RECEIVE
5 3 proc/boot/pipe 10r 0 System RECEIVE
5 4 proc/boot/pipe 10r 0 System RECEIVE
5 5 proc/boot/pipe 10r 0 System RECEIVE
8199 1 sbin/inflator 10r 0 System RECEIVE
8199 2 sbin/inflator 10r 0 System RECEIVE
8199 3 sbin/inflator 10r 0 System RECEIVE
8199 4 sbin/inflator 10r 0 System RECEIVE
53256 1 sbin/io-net 10r 0 DevDebug SIGWAITINFO
53256 2 sbin/io-net 21r 0 DevDebug RECEIVE
53256 3 sbin/io-net 10r 0 DevDebug RECEIVE
53256 4 sbin/io-net 10r 0 DevDebug RECEIVE
53256 5 sbin/io-net 21r 0 DevDebug RECEIVE
53256 6 sbin/io-net 17f 0 DevDebug CONDVAR
53256 7 sbin/io-net 10r 0 DevDebug RECEIVE
53256 8 sbin/io-net 10r 0 DevDebug RECEIVE
53256 10 sbin/io-net 18f 0 DevDebug CONDVAR
77834 1 usr/sbin/inetd 10r 0 DevDebug SIGWAITINFO
81929 1 sbin/devc-pty 10r 0 DevDebug RECEIVE
106507 1 usr/sbin/qconn 10r 0 DevDebug SIGWAITINFO
106507 2 usr/sbin/qconn 10r 0 DevDebug CONDVAR
106507 3 usr/sbin/qconn 10r 0 DevDebug RECEIVE
106507 4 usr/sbin/qconn 10r 0 DevDebug RECEIVE
139276 1 abmax/bin/overseer 75r 0 System RECEIVE
176141 1 bmax/bin/LabMaxGUI 11r 0 System REPLY
176141 2 bmax/bin/LabMaxGUI 11r 0 System RECEIVE
176141 3 bmax/bin/LabMaxGUI 11r 0 System REPLY
192527 1 /photon/bin/Photon 11r 0 System RECEIVE
192528 1 on/bin/io-graphics 12r 0 System RECEIVE
192528 2 on/bin/io-graphics 11r 0 System RECEIVE
192528 3...
View Full Message
|
|
|
|
|
|
|
AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/17/2008 12:07 PM
post16682
|
AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
this is HOT!!!
your pidin request is about to start
within this it is doing its normal statup stuff
ending in a request to proc thread 2 which itself is doing a fseek64() that is serviced by proc thread 10
now thread 10 is trying to answer using MsgReply() but it cant't
whenever proc thread 10 is trying to do MsgReply() it gets interrupted by IR 0x10 which is handled by LMDispatcher in
partition 0
due to the fact that you have a real high IR rate of 3000Hz the MsgReply() can't finish.
Hey QNX guys wake up this is somethig to work on.
@Colin: do you remember that beta hotfix you've done for the MMI3G project where we had a quite simillar problem?
/hp
>-----Ursprüngliche Nachricht-----
>Von: Ken Schumm [mailto:community-noreply@qnx.com]
>Gesendet: Montag, 17. November 2008 16:39
>An: ostech-core_os
>Betreff: Re: AW: AW: RE: RE: New to Adaptive Partitioning,
>problems on PXA270
>
>I ran another test today and captured a wide event trace log
>(attached).
>
>A pidin sched prior to the test shows this:
>---------------------------------------------------------------
>---------------------------------------
> pid tid name prio cpu ExtSched
>STATE
> 1 1 procnto 0f 0 System
>READY
> 1 2 procnto 10r 0 System
>RECEIVE
> 1 3 procnto 10r 0 System
>RECEIVE
> 1 4 procnto 10r 0 System
>RECEIVE
> 1 5 procnto 10r 0 System
>RECEIVE
> 1 6 procnto 10r 0 System
>RECEIVE
> 1 7 procnto 10r 0 System
>RECEIVE
> 1 8 procnto 10r 0 System
>RECEIVE
> 1 9 procnto 10r 0 System
>RECEIVE
> 1 10 procnto 10r 0 DevDebug
>RUNNING
> 1 11 procnto 10r 0 System
>RECEIVE
> 2 1 ot/devf-dbpxa270dp 10r 0 System
>SIGWAITINFO
> 2 2 ot/devf-dbpxa270dp 10r 0 System
>RECEIVE
> 2 3 ot/devf-dbpxa270dp 30r 0 System
>RECEIVE
> 2 4 ot/devf-dbpxa270dp 10r 0 System
>RECEIVE
> 2 5 ot/devf-dbpxa270dp 10r 0 System
>RECEIVE
> 3 1 oot/devc-serpxa250 24r 0 System
>RECEIVE
> 4 1 proc/boot/slogger 30r 0 System
>RECEIVE
> 5 1 proc/boot/pipe 10r 0 System
>SIGWAITINFO
> 5 2 proc/boot/pipe 10r 0 System
>RECEIVE
> 5 3 proc/boot/pipe 10r 0 System
>RECEIVE
> 5 4 proc/boot/pipe 10r 0 System
>RECEIVE
> 5 5 proc/boot/pipe 10r 0 System
>RECEIVE
> 8199 1 sbin/inflator 10r 0 System
>RECEIVE
> 8199 2 sbin/inflator 10r 0 System
>RECEIVE
> 8199 3 sbin/inflator 10r 0 System
>RECEIVE
> 8199 4 sbin/inflator 10r 0 System
>RECEIVE
> 53256 1 sbin/io-net 10r 0 DevDebug
>SIGWAITINFO
> 53256 2 sbin/io-net 21r 0 DevDebug
>RECEIVE
> 53256 3 sbin/io-net 10r 0 DevDebug
>RECEIVE
> 53256 4 sbin/io-net 10r 0 DevDebug
>RECEIVE
> 53256 5 sbin/io-net 21r 0 DevDebug
>RECEIVE
>...
View Full Message
|
|
|
|
|
|
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on
PXA270
|
|
11/17/2008 12:35 PM
post16684
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on
PXA270
Thanks for the analysis, HP.
Ken, you could check this is the case by turning kernel call premption off (-p switch to procnto)
Hans-Peter Reichert wrote:
> this is HOT!!!
> your pidin request is about to start
> within this it is doing its normal statup stuff
> ending in a request to proc thread 2 which itself is doing a fseek64() that is serviced by proc thread 10
> now thread 10 is trying to answer using MsgReply() but it cant't
> whenever proc thread 10 is trying to do MsgReply() it gets interrupted by IR 0x10 which is handled by LMDispatcher in
partition 0
> due to the fact that you have a real high IR rate of 3000Hz the MsgReply() can't finish.
>
> Hey QNX guys wake up this is somethig to work on.
> @Colin: do you remember that beta hotfix you've done for the MMI3G project where we had a quite simillar problem?
>
> /hp
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Ken Schumm [mailto:community-noreply@qnx.com]
>> Gesendet: Montag, 17. November 2008 16:39
>> An: ostech-core_os
>> Betreff: Re: AW: AW: RE: RE: New to Adaptive Partitioning,
>> problems on PXA270
>>
>> I ran another test today and captured a wide event trace log
>> (attached).
>>
>> A pidin sched prior to the test shows this:
>> ---------------------------------------------------------------
>> ---------------------------------------
>> pid tid name prio cpu ExtSched
>> STATE
>> 1 1 procnto 0f 0 System
>> READY
>> 1 2 procnto 10r 0 System
>> RECEIVE
>> 1 3 procnto 10r 0 System
>> RECEIVE
>> 1 4 procnto 10r 0 System
>> RECEIVE
>> 1 5 procnto 10r 0 System
>> RECEIVE
>> 1 6 procnto 10r 0 System
>> RECEIVE
>> 1 7 procnto 10r 0 System
>> RECEIVE
>> 1 8 procnto 10r 0 System
>> RECEIVE
>> 1 9 procnto 10r 0 System
>> RECEIVE
>> 1 10 procnto 10r 0 DevDebug
>> RUNNING
>> 1 11 procnto 10r 0 System
>> RECEIVE
>> 2 1 ot/devf-dbpxa270dp 10r 0 System
>> SIGWAITINFO
>> 2 2 ot/devf-dbpxa270dp 10r 0 System
>> RECEIVE
>> 2 3 ot/devf-dbpxa270dp 30r 0 System
>> RECEIVE
>> 2 4 ot/devf-dbpxa270dp 10r 0 System
>> RECEIVE
>> 2 5 ot/devf-dbpxa270dp 10r 0 System
>> RECEIVE
>> 3 1 oot/devc-serpxa250 24r 0 System
>> RECEIVE
>> 4 1 proc/boot/slogger 30r 0 System
>> RECEIVE
>> 5 1 proc/boot/pipe 10r 0 System
>> SIGWAITINFO
>> 5 2 proc/boot/pipe 10r 0 System
>> RECEIVE
>> 5 3 proc/boot/pipe 10r 0 System
>> RECEIVE
>> 5 4 proc/boot/pipe 10r 0 System
>> RECEIVE
>> 5 5 proc/boot/pipe 10r 0 System
>> RECEIVE
>> 8199 1 sbin/inflator 10r 0 System
>> RECEIVE
>> 8199 2 sbin/inflator 10r 0 System
>> RECEIVE
>> 8199 3 sbin/inflator 10r 0 System ...
View Full Message
|
|
|
|
|
|
|
AW: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/17/2008 1:10 PM
post16686
|
AW: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
I've red the 6.4 release notes but I didn't recognize that -P (capital)
option to procnto - COOOL
/hp
-----Ursprüngliche Nachricht-----
Von: Colin Burgess [mailto:community-noreply@qnx.com]
Gesendet: Mo 17.11.2008 18:35
An: ostech-core_os
Cc:
Betreff: Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
Thanks for the analysis, HP.
Ken, you could check this is the case by turning kernel call premption off (-p switch to procnto)
Hans-Peter Reichert wrote:
> this is HOT!!!
> your pidin request is about to start
> within this it is doing its normal statup stuff
> ending in a request to proc thread 2 which itself is doing a fseek64() that is serviced by proc thread 10
> now thread 10 is trying to answer using MsgReply() but it cant't
> whenever proc thread 10 is trying to do MsgReply() it gets interrupted by IR 0x10 which is handled by LMDispatcher in
partition 0
> due to the fact that you have a real high IR rate of 3000Hz the MsgReply() can't finish.
>
> Hey QNX guys wake up this is somethig to work on.
> @Colin: do you remember that beta hotfix you've done for the MMI3G project where we had a quite simillar problem?
>
> /hp
>
>
>> -----Ursprüngliche Nachricht-----
>> Von: Ken Schumm [mailto:community-noreply@qnx.com]
>> Gesendet: Montag, 17. November 2008 16:39
>> An: ostech-core_os
>> Betreff: Re: AW: AW: RE: RE: New to Adaptive Partitioning,
>> problems on PXA270
>>
>> I ran another test today and captured a wide event trace log
>> (attached).
>>
>> A pidin sched prior to the test shows this:
>> ---------------------------------------------------------------
>> ---------------------------------------
>> pid tid name prio cpu ExtSched
>> STATE
>> 1 1 procnto 0f 0 System
>> READY
>> 1 2 procnto 10r 0 System
>> RECEIVE
>> 1 3 procnto 10r 0 System
>> RECEIVE
>> 1 4 procnto 10r 0 System
>> RECEIVE
>> 1 5 procnto 10r 0 System
>> RECEIVE
>> 1 6 procnto 10r 0 System
>> RECEIVE
>> 1 7 procnto 10r 0 System
>> RECEIVE
>> 1 8 procnto 10r 0 System
>> RECEIVE
>> 1 9 procnto 10r 0 System
>> RECEIVE
>> 1 10 procnto 10r 0 DevDebug
>> RUNNING
>> 1 11 procnto 10r 0 System
>> RECEIVE
>> 2 1 ot/devf-dbpxa270dp 10r 0 System
>> SIGWAITINFO
>> 2 2 ot/devf-dbpxa270dp 10r 0 System
>> RECEIVE
>> 2 3 ot/devf-dbpxa270dp 30r 0 System
>> RECEIVE
>> 2 4 ot/devf-dbpxa270dp 10r 0 System
>> RECEIVE
>> 2 5 ot/devf-dbpxa270dp 10r 0 System
>> RECEIVE
>> 3 1 oot/devc-serpxa250 24r 0 System
>> RECEIVE
>> 4 1 proc/boot/slogger 30r 0 System
>> RECEIVE
>> 5 1 proc/boot/pipe 10r 0 System
>> SIGWAITINFO
>> 5 2 proc/boot/pipe 10r 0 System
>> RECEIVE
>> 5 3 proc/boot/pipe 10r 0 System
>> RECEIVE
>> 5 4 proc/boot/pipe 10r 0 System
>> RECEIVE
>> ...
View Full Message
|
|
|
|
|
|
|
Re: AW: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems
on PXA270
|
|
11/17/2008 1:15 PM
post16687
|
Re: AW: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems
on PXA270
You mean the Priv prio switch?
Hans-Peter Reichert wrote:
>
> I've red the 6.4 release notes but I didn't recognize that -P (capital)
> option to procnto - COOOL
> /hp
>
> -----Ursprüngliche Nachricht-----
> Von: Colin Burgess [mailto:community-noreply@qnx.com]
> Gesendet: Mo 17.11.2008 18:35
> An: ostech-core_os
> Cc:
> Betreff: Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning,
> problems on PXA270
>
> Thanks for the analysis, HP.
>
> Ken, you could check this is the case by turning kernel call premption
> off (-p switch to procnto)
>
> Hans-Peter Reichert wrote:
> > this is HOT!!!
> > your pidin request is about to start
> > within this it is doing its normal statup stuff
> > ending in a request to proc thread 2 which itself is doing a
> fseek64() that is serviced by proc thread 10
> > now thread 10 is trying to answer using MsgReply() but it cant't
> > whenever proc thread 10 is trying to do MsgReply() it gets
> interrupted by IR 0x10 which is handled by LMDispatcher in partition 0
> > due to the fact that you have a real high IR rate of 3000Hz the
> MsgReply() can't finish.
> >
> > Hey QNX guys wake up this is somethig to work on.
> > @Colin: do you remember that beta hotfix you've done for the MMI3G
> project where we had a quite simillar problem?
> >
> > /hp
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Ken Schumm [mailto:community-noreply@qnx.com]
> >> Gesendet: Montag, 17. November 2008 16:39
> >> An: ostech-core_os
> >> Betreff: Re: AW: AW: RE: RE: New to Adaptive Partitioning,
> >> problems on PXA270
> >>
> >> I ran another test today and captured a wide event trace log
> >> (attached).
> >>
> >> A pidin sched prior to the test shows this:
> >> ---------------------------------------------------------------
> >> ---------------------------------------
> >> pid tid name prio cpu ExtSched
> >> STATE
> >> 1 1 procnto 0f 0 System
> >> READY
> >> 1 2 procnto 10r 0 System
> >> RECEIVE
> >> 1 3 procnto 10r 0 System
> >> RECEIVE
> >> 1 4 procnto 10r 0 System
> >> RECEIVE
> >> 1 5 procnto 10r 0 System
> >> RECEIVE
> >> 1 6 procnto 10r 0 System
> >> RECEIVE
> >> 1 7 procnto 10r 0 System
> >> RECEIVE
> >> 1 8 procnto 10r 0 System
> >> RECEIVE
> >> 1 9 procnto 10r 0 System
> >> RECEIVE
> >> 1 10 procnto 10r 0 DevDebug
> >> RUNNING
> >> 1 11 procnto 10r 0 System
> >> RECEIVE
> >> 2 1 ot/devf-dbpxa270dp 10r 0 System
> >> SIGWAITINFO
> >> 2 2 ot/devf-dbpxa270dp 10r 0 System
> >> RECEIVE
> >> 2 3 ot/devf-dbpxa270dp 30r 0 System
> >> RECEIVE
> >> 2 4 ot/devf-dbpxa270dp 10r 0 System
> >> RECEIVE
> >> 2 5 ot/devf-dbpxa270dp 10r 0 System
> >> RECEIVE
> >> 3 1...
View Full Message
|
|
|
|
|
|
|
AW: AW: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/17/2008 1:17 PM
post16688
|
AW: AW: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
yepp, but I've jusst seen that this not new.... hmm
grübel grübel
-----Ursprüngliche Nachricht-----
Von: Colin Burgess [mailto:community-noreply@qnx.com]
Gesendet: Mo 17.11.2008 19:15
An: ostech-core_os
Cc:
Betreff: Re: AW: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
You mean the Priv prio switch?
Hans-Peter Reichert wrote:
>
> I've red the 6.4 release notes but I didn't recognize that -P (capital)
> option to procnto - COOOL
> /hp
>
> -----Ursprüngliche Nachricht-----
> Von: Colin Burgess [mailto:community-noreply@qnx.com]
> Gesendet: Mo 17.11.2008 18:35
> An: ostech-core_os
> Cc:
> Betreff: Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning,
> problems on PXA270
>
> Thanks for the analysis, HP.
>
> Ken, you could check this is the case by turning kernel call premption
> off (-p switch to procnto)
>
> Hans-Peter Reichert wrote:
> > this is HOT!!!
> > your pidin request is about to start
> > within this it is doing its normal statup stuff
> > ending in a request to proc thread 2 which itself is doing a
> fseek64() that is serviced by proc thread 10
> > now thread 10 is trying to answer using MsgReply() but it cant't
> > whenever proc thread 10 is trying to do MsgReply() it gets
> interrupted by IR 0x10 which is handled by LMDispatcher in partition 0
> > due to the fact that you have a real high IR rate of 3000Hz the
> MsgReply() can't finish.
> >
> > Hey QNX guys wake up this is somethig to work on.
> > @Colin: do you remember that beta hotfix you've done for the MMI3G
> project where we had a quite simillar problem?
> >
> > /hp
> >
> >
> >> -----Ursprüngliche Nachricht-----
> >> Von: Ken Schumm [mailto:community-noreply@qnx.com]
> >> Gesendet: Montag, 17. November 2008 16:39
> >> An: ostech-core_os
> >> Betreff: Re: AW: AW: RE: RE: New to Adaptive Partitioning,
> >> problems on PXA270
> >>
> >> I ran another test today and captured a wide event trace log
> >> (attached).
> >>
> >> A pidin sched prior to the test shows this:
> >> ---------------------------------------------------------------
> >> ---------------------------------------
> >> pid tid name prio cpu ExtSched
> >> STATE
> >> 1 1 procnto 0f 0 System
> >> READY
> >> 1 2 procnto 10r 0 System
> >> RECEIVE
> >> 1 3 procnto 10r 0 System
> >> RECEIVE
> >> 1 4 procnto 10r 0 System
> >> RECEIVE
> >> 1 5 procnto 10r 0 System
> >> RECEIVE
> >> 1 6 procnto 10r 0 System
> >> RECEIVE
> >> 1 7 procnto 10r 0 System
> >> RECEIVE
> >> 1 8 procnto 10r 0 System
> >> RECEIVE
> >> 1 9 procnto 10r 0 System
> >> RECEIVE
> >> 1 10 procnto 10r 0 DevDebug
> >> RUNNING
> >> 1 11 procnto 10r 0 System
> >> RECEIVE
> >> 2 1 ot/devf-dbpxa270dp 10r 0 System
> >> SIGWAITINFO
> >> 2 2 ot/devf-dbpxa270dp 10r 0 System
> >> RECEIVE
> >> 2 3...
View Full Message
|
|
|
|
|
|
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
11/17/2008 1:37 PM
post16689
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
You're onto something, with the -p option to procnto it worked.
I've attached another event log for the -p test if you're interested.
PS - I never noticed that the procnto options don't appear in 'pidin arg' before, that had me confused for awhile (easy
to do).
> Thanks for the analysis, HP.
>
> Ken, you could check this is the case by turning kernel call premption off (-p
> switch to procnto)
[...]
|
|
|
|
|
|
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
12/01/2008 1:42 PM
post17668
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
> You're onto something, with the -p option to procnto it worked.
>
> I've attached another event log for the -p test if you're interested.
>
> PS - I never noticed that the procnto options don't appear in 'pidin arg'
> before, that had me confused for awhile (easy to do).
>
> > Thanks for the analysis, HP.
> >
> > Ken, you could check this is the case by turning kernel call premption off (
> -p
> > switch to procnto)
>
> [...]
I haven't heard anything else on this and was wondering - do you consider disabling kernel preemption to be an official
solution in this case? Or are you folks thinking about a fix?
Please note that this is not a showstopper for us. I was evaluating APS for possible use in current and future products
but it is not currently in a shipping product.
|
|
|
|
|
|
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on
PXA270
|
|
12/01/2008 1:56 PM
post17670
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on
PXA270
Hi Ken,
We do consider it a problem, but it's not a simple one to fix. However we are considering solutions
to this issue.
I'll try and keep you updated as we make progress.
Colin
Ken Schumm wrote:
>> You're onto something, with the -p option to procnto it worked.
>>
>> I've attached another event log for the -p test if you're interested.
>>
>> PS - I never noticed that the procnto options don't appear in 'pidin arg'
>> before, that had me confused for awhile (easy to do).
>>
>>> Thanks for the analysis, HP.
>>>
>>> Ken, you could check this is the case by turning kernel call premption off (
>> -p
>>> switch to procnto)
>> [...]
>
> I haven't heard anything else on this and was wondering - do you consider disabling kernel preemption to be an
official solution in this case? Or are you folks thinking about a fix?
>
> Please note that this is not a showstopper for us. I was evaluating APS for possible use in current and future
products but it is not currently in a shipping product.
>
>
> _______________________________________________
> OSTech
> http://community.qnx.com/sf/go/post17668
>
--
cburgess@qnx.com
|
|
|
|
|
|
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
12/01/2008 2:12 PM
post17671
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
> Hi Ken,
>
> We do consider it a problem, but it's not a simple one to fix. However we are
> considering solutions
> to this issue.
>
> I'll try and keep you updated as we make progress.
>
> Colin
Thanks Colin, I appreciate it.
It doesn't sound at all like an easy fix, so good luck!
|
|
|
|
|
|
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
|
|
12/03/2008 2:15 AM
post17816
|
Re: AW: AW: AW: RE: RE: New to Adaptive Partitioning, problems on PXA270
strange my replies through do not make it, this is the second ....
remember that this is not only an APS issue, it is independant from APS just remember the MMI3G project.
I would say that the way you've done it the first time (assuming I remember this right) was not to bad - try to finish
the k-call n times and then force the completion.
What about your scheduler gurus - do they hav any further ideas?
/hp
|
|
|
|
|
|