|
Chris Li(deleted)
|
MME related processes can not be slayed or killed after MME crashed
|
|
Chris Li(deleted)
05/12/2009 8:56 PM
post29326
|
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
|
|
|
|
|
