Jump to ID:
Multimedia

Project Home

Documents

Discussions

Wiki

Project Info
Forum Topic - MME related processes can not be slayed or killed after MME crashed: (5 Items)
   
 
 
MME related processes can not be slayed or killed after MME crashed  
Hi,

The issue I found is as follows:

Description:

When MME suffers a problem during playback on iPod devices, there are two MME processes (io-media-generic and mme-
generic) which can not be slayed or killed by slay or kill command until reboot the neutrino RTOS. 
(Please note that in this case, the MME problem during playback is created artificially just to let the Aviage 
Multimedia Sutie crash, so we can see the issue of some MME related processes just stuck on system and can not be slayed
/killed after MME crash.)


How To Reproduce: 

1) Enable verbose=5 for iofs-ipod driver on the configuration of io-fs-media.

2) Start Aviage Multimedia Suite then play a track with album artwork on iPod by MME.

3) Use corresponding API functions to get the album artwork image from the current playing track on the connected iPod. 


4) With the verbose = 5 of iofs-iPod driver, the MME will print out all the iAP commands between MME and the connected 
iPod on console(terminal). During it is printing the iAP command RetTrackArtworkData which takes long time to finish due
 to large amount of data to print, the playback stops and the whole Aviage Mulitmedia Suite become not functional.

5) After problem occurs, disconnect the iPod, terminate the user application program (i.e., the one which implements API
 function calls), then use system command "slay -fv io-fs-media qdb io-media-generic mme-generic mcd" to slay MME and 
QDB process, and find that io-media-generic and mme-generic processes still remain in system after being slayed. It 
doesn't help even use kill command to kill them individually unless reboot the neutrino system.


Additional Information:

1) I am using USB to connect to the iPod.

2) The target hardware is Freescale i.Max31 ADS board

3) I tried using hub and without hub in the circuit, the problem remains the same.

4) The pidin info is as follows:

a. The pidin output for the case of just right after the problem occurred and before performing any slays (Please note 
that the iPod has been disconnected and the application program has been terminated):
pidin
pid tid name prio STATE
Blocked
1 1 oc/boot/procnto-v6 0f
READY
1 2 oc/boot/procnto-v6 255r RECEIVE
1
1 3 oc/boot/procnto-v6 10r
RUNNING
1 4 oc/boot/procnto-v6 10r RECEIVE
1
1 5 oc/boot/procnto-v6 10r RECEIVE
1
1 6 oc/boot/procnto-v6 10r RECEIVE
1
1 7 oc/boot/procnto-v6 10r RECEIVE
1
1 8 oc/boot/procnto-v6 10r RECEIVE
1
1 9 oc/boot/procnto-v6 10r RECEIVE
1
1 10 oc/boot/procnto-v6 10r RECEIVE
1
1 11 oc/boot/procnto-v6 12r RECEIVE
1
1 12 oc/boot/procnto-v6 10r RECEIVE
1
2 1 c/boot/devc-sermx1 24r RECEIVE
1
3 1 proc/boot/slogger 10r RECEIVE
1
4 1 proc/boot/pipe 10r
SIGWAITINFO
4 2 proc/boot/pipe 10r RECEIVE
1
4 3 proc/boot/pipe 10r RECEIVE
1
4 4 proc/boot/pipe 10r RECEIVE
1
5 1 roc/boot/io-pkt-v4 21r
SIGWAITINFO
5 2 roc/boot/io-pkt-v4 21r RECEIVE
1
5 3 roc/boot/io-pkt-v4 21r RECEIVE
14
6 1 proc/boot/devc-pty 10r RECEIVE
1
7 1 -etfs-imx31ads_512 10r RECEIVE
1
7 2 -etfs-imx31ads_512 8r
NANOSLEEP
8 1 /boot/devf-mx31ads 10r
SIGWAITINFO
8 2 /boot/devf-mx31ads 10r RECEIVE
1
9 1 proc/boot/io-usb 10r
SIGWAITINFO
9 2 proc/boot/io-usb 21r RECEIVE
4
9 3 proc/boot/io-usb 21r RECEIVE
1
9 4 proc/boot/io-usb 49r RECEIVE
7
9 5 proc/boot/io-usb 10r
NANOSLEEP
9 6 proc/boot/io-usb 10r RECEIVE
7
9 8 proc/boot/io-usb 10r RECEIVE
7
9 9 proc/boot/io-usb 10r RECEIVE
7
10 1 bin/enum-devices 10r REPLY
4
11 1 bin/enum-usb 10r
SIGWAITINFO
11 2 bin/enum-usb 10r REPLY
9
12 1 oc/boot/spi-master 10r
SIGWAITINFO
12 2 oc/boot/spi-master 21r RECEIVE
4
4109 1 proc/boot/io-audio 21r
SIGWAITINFO
4109 2 proc/boot/io-audio 51r RECEIVE
4
4109 3 proc/boot/io-audio 22r RECEIVE
1
4109 4 proc/boot/io-audio 22r RECEIVE
1
4109 5 proc/boot/io-audio 21r RECEIVE
1
4109 6 proc/boot/io-audio 22r RECEIVE
1
4110 1 oc/boot/io-display 10r
SIGWAITINFO
4110 3 oc/boot/io-display 10r RECEIVE
1
4110 4...
View Full Message
Re: MME related processes can not be slayed or killed after MME crashed  
>Hi,
>
>The issue I found is as follows:
>
>Description:
>
>When MME suffers a problem during playback on iPod devices, there are two
>MME processes (io-media-generic and mme-generic) which can not be slayed
>or killed by slay or kill command until reboot the neutrino RTOS.
>(Please note that in this case, the MME problem during playback is created
>artificially just to let the Aviage Multimedia Sutie crash, so we can see
>the issue of some MME related processes just stuck on system and can not
>be slayed/killed after MME crash.)

A similar issue has been recorded here. If you look at io-media-generic you
can see that it is blocked on io-audio. If you slay io-audio then the other
two processes should be recovered.

There is a fix in 6.4.1 (pending release) where this should be addressed.
I'm not certain of schedules where a fix would be pushed to previous
releases.

PR 67806 was filed to track the original issue.

>4109 1 proc/boot/io-audio 21r
>SIGWAITINFO
>4109 2 proc/boot/io-audio 51r RECEIVE
>4
>4109 3 proc/boot/io-audio 22r RECEIVE
>1
>4109 4 proc/boot/io-audio 22r RECEIVE
>1
>4109 5 proc/boot/io-audio 21r RECEIVE
>1
>4109 6 proc/boot/io-audio 22r RECEIVE
>1

>131097 1 n/io-media-generic 14r CONDVAR
>(0x1587e0)
>131097 2 n/io-media-generic 14f MUTEX (0x16e4e4) 131097-01
>#1
>131097 3 n/io-media-generic 10r
>DEAD
>131097 4 n/io-media-generic 22r REPLY
>4109

-> thread is blocked on audio


>131097 6 n/io-media-generic 14f CONDVAR
>(0x171068)
>131097 7 n/io-media-generic 10r CONDVAR
>(0x16e4e4)

>131098 1 r/sbin/mme-generic 10r RECEIVE
>7
>131098 2 r/sbin/mme-generic 11r RECEIVE
>1
>131098 3 r/sbin/mme-generic 6r RECEIVE
>4
>131098 4 r/sbin/mme-generic 10r CONDVAR
>(0x1ca4f8)
>131098 5 r/sbin/mme-generic 10r CONDVAR
>(0x1ca4f8)
>131098 6 r/sbin/mme-generic 10r CONDVAR
>(0x1ca438)
>131098 7 r/sbin/mme-generic 10r REPLY
>131097
>131098 8 r/sbin/mme-generic 10r CONDVAR
>(0x1ca2c4)
>131098 9 r/sbin/mme-generic 10r SEND
>131098
>131098 10 r/sbin/mme-generic 10r CONDVAR
>(0x1ca550)
>131098 11 r/sbin/mme-generic 10r RECEIVE
>7
>131098 12 r/sbin/mme-generic 10r SEND
>131097
>131098 13 r/sbin/mme-generic 10r RECEIVE
>7
>131098 14 r/sbin/mme-generic 10r CONDVAR
>(0x1ca4f8)
>131098 15 r/sbin/mme-generic 10r CONDVAR
>(0x1ca4f8)
Re: MME related processes can not be slayed or killed after MME crashed  
Hi,

I tried slaying io-audio, it seems the the problem still remains, i.e., io-media-generic and mme-generic still can not 
be slayed after that. 

Attached the pidin info after slaying io-audio and still failed to kill those two MME processes as follows:

1 oc/boot/procnto-v6   0f READY                                   
       1   2 oc/boot/procnto-v6 255r RECEIVE     1                           
       1   3 oc/boot/procnto-v6  10r RECEIVE     1                           
       1   5 oc/boot/procnto-v6 255r RECEIVE     1                           
       1   7 oc/boot/procnto-v6  10r RECEIVE     1                           
       1   8 oc/boot/procnto-v6  10r RECEIVE     1                           
       1   9 oc/boot/procnto-v6  10r RECEIVE     1                           
       1  10 oc/boot/procnto-v6  10r RUNNING                                 
       1  11 oc/boot/procnto-v6  10r RECEIVE     1                           
       1  12 oc/boot/procnto-v6  10r RECEIVE     1                           
       1  13 oc/boot/procnto-v6  10r RECEIVE     1                           
       1  14 oc/boot/procnto-v6  10r RECEIVE     1                           
       2   1 c/boot/devc-sermx1  21r RECEIVE     1                           
       3   1 proc/boot/slogger   21r RECEIVE     1                           
       4   1 proc/boot/pipe      10r SIGWAITINFO                             
       4   2 proc/boot/pipe      10r RECEIVE     1                           
       4   3 proc/boot/pipe      10r RECEIVE     1                           
       4   4 proc/boot/pipe      10r RECEIVE     1                           
       5   1 roc/boot/io-pkt-v4  21r SIGWAITINFO                             
       5   2 roc/boot/io-pkt-v4  10r RECEIVE     1                           
       5   3 roc/boot/io-pkt-v4  21r RECEIVE     14                          
       6   1 proc/boot/devc-pty  20r RECEIVE     1                           
       7   1 -etfs-imx31ads_512  10r RECEIVE     1                           
       7   2 -etfs-imx31ads_512   8r NANOSLEEP                               
       8   1 /boot/devf-mx31ads  10r SIGWAITINFO                             
       8   2 /boot/devf-mx31ads  10r RECEIVE     1                           
       9   1 proc/boot/io-usb    10r SIGWAITINFO                             
       9   2 proc/boot/io-usb    21r RECEIVE     4                           
       9   3 proc/boot/io-usb    21r RECEIVE     1                           
       9   4 proc/boot/io-usb    12r RECEIVE     7                           
       9   5 proc/boot/io-usb    10r NANOSLEEP                               
       9   6 proc/boot/io-usb    10r RECEIVE     7                           
       9   7 proc/boot/io-usb    10r RECEIVE     7                           
      10   1 bin/enum-devices    10r REPLY       4                           
      11   1 bin/enum-usb        10r SIGWAITINFO                             
      11   2 bin/enum-usb        10r REPLY       9                           
      12   1 oc/boot/spi-master  10r SIGWAITINFO                             
      12   2 oc/boot/spi-master  21r RECEIVE     4                           
    4110   1 oc/boot/io-display  10r SIGWAITINFO                             
    4110   3 oc/boot/io-display  10r RECEIVE     1                           
    4110   4 oc/boot/io-display  10r RECEIVE     3                           
    4110   5 oc/boot/io-display  10r RECEIVE     1                           
    4111   1 /boot/i2c-imx31ads  12r RECEIVE     1                           
    8208   1 proc/boot/qconn     10r SIGWAITINFO                             
    8208   2 proc/boot/qconn     10r CONDVAR     (0x11da7c)                  
    8208   3 proc/boot/qconn     10r RECEIVE     1                           
    8208   4 proc/boot/qconn     10r RECEIVE     3                           
    8210   1 proc/boot/ksh      ...
View Full Message
Re: MME related processes can not be slayed or killed after MME crashed  
There was a bug in previous releases that would cause this behaviour.   Once io-media-generic got blocked on io-audio, 
it would not recover.  The latest release has it fixed.
Re: MME related processes can not be slayed or killed after MME crashed  
> b. The pidin output after performing slays, and from the outpout, we can see 
> that the process io-media-generic 131097 and mme-generic 131098 still remain 
> running on system after slay:
> # slay -fv io-fs-media qdb io-media-generic mme-generic mcd
> slay: usr/sbin/io-fs-media 126998 on (tty not known)
> slay: usr/sbin/io-fs-media 131099 on (tty not known)
> slay: usr/sbin/qdb 131095 on (tty not known)
> slay: usr/sbin/io-media-generic 131097 on (tty not known)
> slay: usr/sbin/mme-generic 131098 on (tty not known)
> slay: bin/mcd 131096 on (tty not known)

Have you tried using "slay -9f ... " ? Usually works for hard-to-slay processes...