Full RT kernel problem on arm

Full RT kernel problem on arm

[Warter]

Hello to all,

I tried to use RT kernel for my streaming server (Music Player Daemon)
on my Hummingboard (Debian Jessie). If I send some commands
(stop-start-next track) in row the mpd starts to eat up the resources.
It freezes and I cannot kill it or reboot/shutdown the board. I have
to reset the board, no other solution. It works fine if I use Basic
RT. I tried with several kernel versions (3.14, 3.18, 4.0, 4.1).

Thanks for any comment regarding issue or better way for bug-report,
Warter

Re: Full RT kernel problem on arm

[Daniel Wagner]

Hi,

On 05/22/2015 02:36 PM, Warter wrote:
> Hello to all,
> 
> I tried to use RT kernel for my streaming server (Music Player Daemon)
> on my Hummingboard (Debian Jessie). If I send some commands
> (stop-start-next track) in row the mpd starts to eat up the resources.
> It freezes and I cannot kill it or reboot/shutdown the board. I have
> to reset the board, no other solution. It works fine if I use Basic
> RT. I tried with several kernel versions (3.14, 3.18, 4.0, 4.1).
> 
> Thanks for any comment regarding issue or better way for bug-report,

Without any logs it is pretty hard to help here. Do yoi happen to have
an serial port for logging? In this case redirect the console output.

HTH,
Daniel

Re: Full RT kernel problem on arm

[Warter]

Hi,

> Without any logs it is pretty hard to help here. Do yoi happen to have
> an serial port for logging? In this case redirect the console output.

I dont have serial port on Hummingboard. Unfortunately I am not
familiar with debugging, but I can provide anything what you need.

Thanks,
Szilard


On 27 May 2015 at 09:10, Daniel Wagner <wagi@monom.org> wrote:
> Hi,
>
> On 05/22/2015 02:36 PM, Warter wrote:
>> Hello to all,
>>
>> I tried to use RT kernel for my streaming server (Music Player Daemon)
>> on my Hummingboard (Debian Jessie). If I send some commands
>> (stop-start-next track) in row the mpd starts to eat up the resources.
>> It freezes and I cannot kill it or reboot/shutdown the board. I have
>> to reset the board, no other solution. It works fine if I use Basic
>> RT. I tried with several kernel versions (3.14, 3.18, 4.0, 4.1).
>>
>> Thanks for any comment regarding issue or better way for bug-report,
>
> Without any logs it is pretty hard to help here. Do yoi happen to have
> an serial port for logging? In this case redirect the console output.
>
> HTH,
> Daniel

Re: Full RT kernel problem on arm

[Daniel Wagner]

On 05/27/2015 09:33 AM, Warter wrote:
>> Without any logs it is pretty hard to help here. Do yoi happen to have
>> an serial port for logging? In this case redirect the console output.
> 
> I dont have serial port on Hummingboard. Unfortunately I am not
> familiar with debugging, but I can provide anything what you need.

I am not familiar with the Humminboard board, though it looks like the
UART is available via the GPIO pins. Getting a debugging setup running
is not simple task, though it might help in future :)

Another way to debug this is trying to reduce the problem. From your
description the mpd itself could just have a severe memory leak and that
is not handled correctly. As starting point you could try to get some
mpd logs out before it freezes?

Re: Full RT kernel problem on arm

[Warter]

Hi,

I collected some logs I hope it helps.

mpd.log:

May 27 19:13 : client: [29] opened from 127.0.0.1:37393
May 27 19:13 : client: [29] closed
May 27 19:13 : client: [12] process command "next"
May 27 19:13 : playlist: play 1:"NAS/first.flac"
May 27 19:13 : player: played "NAS/second.flac"
May 27 19:13 : playlist: queue song 1:"NAS/third.flac"
May 27 19:13 : client: [12] command returned 0
May 27 19:13 : client: [27] process command "status"
May 27 19:13 : client: [27] command returned 0
May 27 19:13 : client: [27] process command "playlistinfo 5"
May 27 19:13 : client: [27] command returned 0
May 27 19:13 : client: [27] process command "close"
May 27 19:13 : client: [27] command returned 3
May 27 19:13 : client: [27] closed
May 27 19:13 : client: [12] process command "status"
May 27 19:13 : client: [12] command returned 0
May 27 19:13 : client: [12] process command "plchangesposid "14""
May 27 19:13 : client: [12] command returned 0
May 27 19:13 : client: [13] process command "idle"
May 27 19:13 : client: [13] command returned 1
May 27 19:13 : client: [12] process command "currentsong"
May 27 19:13 : client: [12] command returned 0
May 27 19:13 : decoder_thread: probing plugin flac
May 27 19:13 : decoder: audio_format=44100:16:2, seekable=true
May 27 19:13 : client: [30] opened from 127.0.0.1:37400
May 27 19:13 : client: [31] opened from 127.0.0.1:37402
May 27 19:13 : client: [30] process command "status"

w:
 19:13:19 up 2 min,  2 users,  load average: 0.75, 0.23, 0.09
 19:13:50 up 2 min,  2 users,  load average: 3.21, 0.87, 0.31
 19:14:55 up 3 min,  2 users,  load average: 5.72, 2.07, 0.76
 19:15:48 up 4 min,  2 users,  load average: 6.49, 2.90, 1.12
 19:18:28 up 7 min,  2 users,  load average: 6.21, 4.35, 1.96
 19:20:01 up 8 min,  2 users,  load average: 6.05, 4.78, 2.33

ps:
mpd       1875  0.4  7.4 124636 76696 ?        SLsl 19:11   0:01
/usr/bin/mpd --verbose /etc/mpd.conf

after kill:
mpd       1875  0.3  0.0      0     0 ?        Zsl  19:11   0:01 [mpd] <defunct>

It is interesting because if I use "Basic RT", there is no problem.

Thanks,
Szilard

Re: Full RT kernel problem on arm

[Jeremy Jongepier]

[-- Attachment #1: Type: text/plain, Size: 216 bytes --]

On 05/27/2015 07:25 PM, Warter wrote:
> It is interesting because if I use "Basic RT", there is no problem.

Then why not stick with that? A real-time kernel doesn't sound better as
far as I know ;)

Jeremy


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]