242 replies to this topic

[Erik Slagter]

 

 

This OpenViX filepush.cpp

 

Question remains, what is the difference. I see my own code, with added #ifdef's for HiSil...

The difference is it doesn't freeze enigma, requiring a restart.

 

Don't be obnoxious. You know what I mean. What is the functional difference in the code that makes the difference.

[Erik Slagter]

Try maintaining (developing, testing) code that is littered with IF BOX THEN blocks for every box that is supported...

Yes exactly that, that is something we are really trying to avoid.

 

And if drivers where developed correctly, it really should not be necessary in the first place.

[Erik Slagter]

 

After 4 months of trying to help PLi and coming up against the normal immovable object he eventually gave up and ask me to revert OpenViX to his original working commits. Extremely frustrating. The following were a couple of comments from Simon at the time:

• Erik's going round and round, trying so hard to fix the problem without basing it on my two simple PRs. He's removed the thread signal unblock now, which is wrong, so we've got half a fix, but with more code.
• My approach is that the existing code has been largely unaltered for 7 or 8 years, which is 7 or 8 years' worth of testing, so let's not change it more than we have to.
• Erik has ignored my advice to unblock SIGUSR1 explicitly on the thread as per my initial recommendation in November. I think I'll wait until the user with the XTrend box submits a log with 100 thread stop retries and Erik is really baffled before suggesting it again.
• I'm afraid I got a bit fed up with being a guinea pig for this. PLi weren't interested in taking the actual fix from the guy that had a debugger on a box that was affected and seem to be more interested in fixing bugs that don't actually manifest and introducing more that didn't exist before. It's just not acceptable for the primary function of a PVR to be broken for 4 months.

 

 

And I am afraid you're not entirely correct here.

 

I did not do this:

 

"He's removed the thread signal unblock now, which is wrong"

 

If you look again in the code, you will the signal is indeed unblocked, but maybe not in the way that you or Simon would expect. Have a good look at the pthread_sigmask manpage to see how it works. Do you really think I would submit code that I did not test myself, including the delivery of the signal? It just works, most of the time. If the signal was not unblocked, it would never work. So, this is not helping.

 

"Erik has ignored my advice to unblock SIGUSR1 explicitly on the thread"

 

Exactly the same comment. Not helping.

 

Just because the code takes a slightly different approach you're expecting, it doesn't mean it can't work and it isn't tested.

 

I am human, I can be stubborn and I make mistakes, but I am also a trained software engineer, earned a degree on it so don't talk to me like I am an idiot.

[Erik Slagter]

At this moment I am suspecting the read system call to not be interrupted by the signal. According to the manpage system calls are only interrupted by signals when they're expected to take "some time". There is no hard specification, but they mention some examples, e.g. reads/writes to/from a local disk are expected to be a "quick" operation and cannot be interrupted. Read/writes to/from a remote file system (like NFS and SMB) can be considered to be a "slow operation" and can probably be interrupted.

 

At the same time I am seeing that I don't have problems, while I am using an NFS mount. The same goes for Wanwizard. Maybe the people that are experiencing issue are using a local disk, which could explain the difference. The exact behaviour of read/write can also be influenced by glibc, which, hey, happens to be updated when we moved to OE Zeus, from which point we are seeing the issues.

 

So I think the next step really should be debugging this. I'd like to ask anyone who has a frozen enigma, to login to the box, start strace on enigma, and check if any thread is blocking on a read(). If that turns out to be difficult, I could add some debugging code to show this.

[Huevos]

@Erik,

 

Look at our history here: https://github.com/O...vb/filepush.cpp

 

You can see all your commits. Up until those commits were reverted the freeze was happening, and it is still happening PLi.

 

As for the comments (correct or not) they are Simon's not mine and obviously what he believed at the time.

 

Anyway, you said, "Just because the code takes a slightly different approach you're expecting, it doesn't mean it can't work and it isn't tested", but the freeze remains so whatever testing was done didn't provoke the condition.

Edited by Huevos, 22 August 2023 - 18:37.

[WanWizard]

Here's an enigma with Simon's method of signal handing:

 

enigma2_3.9+git20839+854d615-r0.0_vuduo4kse.ipk

 

I see another difference, which is that in VIX kill() is always and directly executed on stop(), while we have a timeout look which sends the signal up to 100 times, and doesn't kill if the loop ends before the signal is acted upon.

 

@paneologist,

 

Any chance to test this one?

[paneologist]

Here's an enigma with Simon's method of signal handing:

 

enigma2_3.9+git20839+854d615-r0.0_vuduo4kse.ipk

 

I see another difference, which is that in VIX kill() is always and directly executed on stop(), while we have a timeout look which sends the signal up to 100 times, and doesn't kill if the loop ends before the signal is acted upon.

was away yesterday. DId now install.

 

So I think the next step really should be debugging this. I'd like to ask anyone who has a frozen enigma, to login to the box, start strace on enigma, and check if any thread is blocking on a read(). If that turns out to be difficult, I could add some debugging code to show this.

will do if this happens again
 

[Huevos]

 

Here's an enigma with Simon's method of signal handing:

 

enigma2_3.9+git20839+854d615-r0.0_vuduo4kse.ipk

 

I see another difference, which is that in VIX kill() is always and directly executed on stop(), while we have a timeout look which sends the signal up to 100 times, and doesn't kill if the loop ends before the signal is acted upon.

was away yesterday. DId now install.

 

So I think the next step really should be debugging this. I'd like to ask anyone who has a frozen enigma, to login to the box, start strace on enigma, and check if any thread is blocking on a read(). If that turns out to be difficult, I could add some debugging code to show this.

will do if this happens again
 

 

opkg install strace

So you need to attach strace to the running process that is frozen. To do that you have to start it using the enigma pid.

strace -p `pidof enigma2`

 

[paneologist]

ok. just tested a lot.

ran epgrefresh with fake recording.

made 51 concurrent recordings.

ran epgrefresh again.

no problems yet.

an end of recording looks like that in the logs now:

2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [TIMER] stop recording on tuner: G
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBServiceRecord] stop recording!
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] read got interrupted by signal, stop: 0
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: message repeated 1087 times: [ [eFilePushThreadRecorder] read got interrupted by signal, stop: 0]
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] stopping thread
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePush] SIGUSR1 received
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] read got interrupted by signal, stop: 1
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBRecordFileThread] waiting for aio to complete
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBRecordFileThread] buffer usage histogram (40 buffers of 188 kB)
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBRecordFileThread]   1:     33
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBRecordFileThread]   2:     33
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] THREAD STOP

 

[WanWizard]

Ok, that makes me carefully optimistic.

 

Fingers crossed it stays this way. If you still don't have any issues in a week or so, I'm confident I can commit this code for wider testing.

[Huevos]

 

ok. just tested a lot.

ran epgrefresh with fake recording.

made 51 concurrent recordings.

ran epgrefresh again.

no problems yet.

an end of recording looks like that in the logs now:

2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [TIMER] stop recording on tuner: G
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBServiceRecord] stop recording!
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] read got interrupted by signal, stop: 0
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: message repeated 1087 times: [ [eFilePushThreadRecorder] read got interrupted by signal, stop: 0]
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] stopping thread
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePush] SIGUSR1 received
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] read got interrupted by signal, stop: 1
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBRecordFileThread] waiting for aio to complete
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBRecordFileThread] buffer usage histogram (40 buffers of 188 kB)
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBRecordFileThread]   1:     33
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eDVBRecordFileThread]   2:     33
2023-08-23T14:15:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] THREAD STOP

Is that using the binary from WanWizard?

[paneologist]

Is that using the binary from WanWizard?

 

it is

[piplan1966]

 

 

If so then many thanks to notify us about it after almost 3 years.

Read the entire thread carefully and you'll understand

https://forums.openp...es-in-filepush/

Sorry, we couldn't find that!

[WanWizard]

That is a non-public thread, you can't read it.

[paneologist]

unfortunately this morning, the box got stuck again.

Clock on display shows 01:09

 

I can only find that matching event in the logs, which looks normal, besides the spinner:

2023-08-24T01:10:00+02:00 stb1.swabian.net enigma2: [TIMER] stop recording on tuner: B
2023-08-24T01:10:00+02:00 stb1.swabian.net enigma2: [eDVBServiceRecord] stop recording!
2023-08-24T01:10:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] read got interrupted by signal, stop: 0
2023-08-24T01:10:00+02:00 stb1.swabian.net enigma2: message repeated 1302 times: [ [eFilePushThreadRecorder] read got interrupted by signal, stop: 0]
2023-08-24T01:10:00+02:00 stb1.swabian.net enigma2: [eFilePushThreadRecorder] stopping thread
2023-08-24T01:10:02+02:00 stb1.swabian.net enigma2: [gRC] main thread is non-idle! display spinner!

sorry, do not have the time for further debugging right now. next time i'll run strace

 stb1debuglog12.txt   168.16KB   1 downloads

[Huevos]

@WanWizard,

 

Was your binary built from this: https://github.com/O...igma2/pull/3746

[WanWizard]

No, what I did was replace Erik's code by Simon's code.

Attached Files

•  filepush.diff   3.93KB   6 downloads

[Huevos]

No, what I did was replace Erik's code by Simon's code.

Ok, but the known working code is Dima73's PR.

[littlesat]

Are you 1000% sure? And it does not impact any other features?

Edited by littlesat, 24 August 2023 - 15:55.

[WanWizard]

Ok, but the known working code is Dima73's PR.

 

Have you looked at the diff?

 

If you ignore the IF_HAVE_HISILICON in DIma's post, what you end up with is different signaling.

 

I'll do a line-for-line comparison tonight, to check if I have missed something.

 

If not, At least this proofs that a difference in signal handling is not the root cause of the problem. But afaik it is the only thing Simon changed.

Edited by WanWizard, 24 August 2023 - 16:02.