Reboot-Loop Hunting Season...

evr escribió:

It is very weird because any other files are untouched. Why is damaged only the PM binary?

Probably just bud luck (in this particular case). This is why I predict that next time it can happen with another soft piece...

I suspect the Victor to make some self-destructing code into PipeManagement.

Keltek escribió:

evr escribió:

It is very weird because any other files are untouched. Why is damaged only the PM binary?

Probably just bud luck (in this particular case). This is why I predict that next time it can happen with another soft piece...

I suspect the Victor to make some self-destructing code into PipeManagement.

Yea! Sure! I have seen several pieces of "self-destructing code into PipeManagement": they are hidden in the form of "system()" calls to busybox ...

Keltek escribió:[...]So... - we can check of damaged PipeManagement and if it is damaged, boot without it[...]

I think we should implement this turnaround as soon as possible. In fact it is just a matter of writing the rcS script in the proper way; I mean, as it is now the invocations of both DvdPlayae and RootApp are correctly conditioned by the corresponding sanity checks, but PipeManagemet is unconditionally invoqued!! :(. So a proper rcS invocation code should look something like:

Código:

[...]
if [ -f $DEFAULT_AP_DIR/DvdPlayer ] && [ -x $DEFAULT_AP_DIR/DvdPlayer ]; then
  cd $DEFAULT_AP_DIR
  if [ -f $DEFAULT_AP_DIR/RootApp ] && [ -x $DEFAULT_AP_DIR/RootApp ]; then
    echo Running dvdplayer with RootApp
    tail -f /tmp/command_sender.txt | ./RootApp DvdPlayer >> /tmp/appout &
else
  echo Running dvdplayer
  tail -f /tmp/command_sender.txt | ./DvdPlayer >> /tmp/appout &
fi
if [ -f /usr/local/etc/PipeManagement ] && [ -x /usr/local/etc/PipeManagement ]; then
  cat /tmp/appout | /usr/local/etc/PipeManagement/PipeManagement &
fi
[...]


Best,

This check will not works, because the damaged PipeManagement is regular file and is executable (have the executable flag set) but the data is overwritten.
See this:

Código:

Ondra@L3AGL6V:/cygdrive/d/Workspace-HELIOS-LG/temp/rebootloop$ ls -al
-rwxrwxrwx  1 Ondra None 230769 Dec  7 21:53 PipeManagement*
-rwxrwxrwx  1 Ondra None 230769 Feb  2 22:33 PipeManagement.BAD*

Ondra@L3AGL6V:/cygdrive/d/Workspace-HELIOS-LG/temp/rebootloop$ file *
PipeManagement:    ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x3040000, not stripped
PipeManagement.BAD: data

Keltek escribió:This check will not works, because the damaged PipeManagement is regular file and is executable (have the executable flag set) but the data is overwritten.
See this:

Código:

Ondra@L3AGL6V:/cygdrive/d/Workspace-HELIOS-LG/temp/rebootloop$ ls -al
-rwxrwxrwx  1 Ondra None 230769 Dec  7 21:53 PipeManagement*
-rwxrwxrwx  1 Ondra None 230769 Feb  2 22:33 PipeManagement.BAD*

Ondra@L3AGL6V:/cygdrive/d/Workspace-HELIOS-LG/temp/rebootloop$ file *
PipeManagement:    ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), statically linked, with unknown capability 0xf41 = 0x756e6700, with unknown capability 0x70100 = 0x3040000, not stripped
PipeManagement.BAD: data

Right! So we need a more clever check... What happens if you try to execute it? does it cause an immediate reboot? or do you get some recoverable error (from the shell)? Alternatively we should compute a checksum or at list have two copies and make a diff and only invoque it if the checksum and/or the diff are positive...

Best,

Yesterday I have an idea about md5sum, but this md5sum should be updated every time the PM is updated. Now, I prefer md5sum checking. This will slightly slow the booting, but not to much.

Keltek escribió:Yesterday I have an idea about md5sum, but this md5sum should be updated every time the PM is updated. Now, I prefer md5sum checking. This will slightly slow the booting, but not to much.

Yes, md5sumshould be O.K.

Best,

Hello friends
Sorry, been *VERY* busy yesterday and today.
Very glad of the posts you are writing

Yes, we noted also some strange behaviour in this part of memory;
Keltek, remember the kernel driver of IR that was corrupted from time to time ...
yes, is seems it is the same reason!!!!


So, a check of md5sum of PM is a very nice solution!!!

vic1972 escribió:Yes, we noted also some strange behaviour in this part of memory; Keltek, remember the kernel driver of IR that was corrupted from time to time ... yes, is seems it is the same reason!!!!

Agree (...it reinforces my "flash swap overflow" theory )

So, a check of md5sum of PM is a very nice solution!!!

Yep! NOT a "solution", just a very basic turnaround!!

We need to find the cause of these corruptions, not only a way to recover from them.

Best,

Yes, that is clear.
But mean while we could help with workarounds.

I have done this check which works well:
in rcS:

if /usr/bin/md5sum -c /usr/local/etc/PipeManagement/Files/PipeManagement_Boot.md5; then
cat /tmp/appout | /usr/local/etc/PipeManagement/PipeManagement &
fi

I have created a md5sum file and a check, if the check is fine, then PM is launched.

Another solution I have in mind, is instead of launching PM right from the begining (that is why it is place in this memory /usr/local/etc); is to have it started later (around 20 seconds later), and then it can be placed in the other filesystem, for eg. in /root/custom/PM

Then PipeManagement_Boot.md5 is for example like:
c08636925b4f18971a41503b794b76df /usr/local/etc/PipeManagement/PipeManagement

I uploaded all the scripts to SVN and I add some md5sum checking of PM. Please check this out and tell me...

Very good
I like very much the way it is controlled, using var: startpm
Thanks.

I cannot add value, except my encouragements.

I got the infinite reboot syndroma today (again), and girls here were again complaining about this stupid black box, and why their recording failed, and why I purchased that and blah blah blah.. Sigh...

Keep on searching, guys, and thanks for the good useful job done so far !