New reboot loop hunting season

Well,
It looks like the reboot loop issue is significantly better with the latest release ;)

However, the background problem does persists: since the release of HarmonyPack1.3, at least three cases have been reported that show that a corruption of some firmware file has occurred. So I am starting this renewed thread to go on with our efforts to try to finally eradicate this nasty issue.

In my case, I have not had any problem so far (in contrast with HarmonyPack1.2), but I have done two special things:

- Set the flash swap priority lower than the HD priority and set the swappiness to 0
- Disable by default all the services, including lighttpd, and enable them only temporaly when I wan to to do some specific thing.

Even so, I must say that now my LG is somewhat less stable than it was during the three months that I have been working with official LG firmware: some unexpected reboots, a few hangs in OFF at power off, etc.

So let us reopen this hunting session and see what we can do to improve things for future releases...

All the best,

evr escribió:However, the background problem does persists: since the release of HarmonyPack1.3, at least three cases have been reported that show that a corruption of some firmware file has occurred.

Well, now we have at least four reported cases. See this post.

So I think it is time to continue our discussions about possible ways to eradicate this nasty issue.

Best,

evr escribió:However, the background problem does persists: since the release of HarmonyPack1.3, at least three cases have been reported that show that a corruption of some firmware file has occurred.

evr escribió:Well, now we have at least four reported cases. See [...]

One more case: mine. See this post.

After approx. 1 month of normal operation with Harmony Pack v1.3 (with all the services disabled, including lighttpd), today I noticed that PM did not work at all. I opened a telnet connection and, actually, PM was not there. Then I checked "/usr/local/etc/PipeManagement/PipeManagement" and, in fact, it was corrupt. I did an octal dump and all its bytes were "0".

This has happened just one day after I made some tests with a new PM version (see here). It may or may not be related with the corruption, I don't know.

The tests consisted in killing the running PM (the original one from HP-v1.3) and then launching the new version I had just compiled. After the (positive) tests, I killed the new PM version and launched the original one, which did run correctly. I left a recording working and went to sleep. This morning, the LG was hang in OFF. After resetting it, today I have been using the LG two or three times, apparently working normally. But at one point, I've realized that the PM functionalities were missing, and this is how I've discovered the corruption.

I have replaced the original, corrupt PM and its MD5 file with the new PM version and its corresponding MD5 file, and, so far, everything seems to work O.K.

So, please, we do need ideas for this new "hunting season"!

Best,

Hello pal!!

really not good news.
What is the size of your pm executable file? is it much heavier than last version?
did you stripped to eliminate the debug info.?


My idea of a possible solution is to parse the output main app in a different way as it is right now.

right now it is like DvdePlayer | PM (using a named pipe)

I suggest either:
*solution 1* The idea evr commented some time ago, about changing the arch. of pm, and the great image he posted.

*solution 2* is PM to me an isolated process that process a file
DvdPlayer > output_file
PM & (In this case PM open and parse output_file).

well, just some ideas .....