OpenPLi-2.1-beta-dm800-20111028 With sim201-ssl84

I experienced the same w/ OpenPLi, I don't know if it's a bug in SSL or image. Originally I was running a stock/online updated image w/ ssl82 & patched tuner driver, for months, ran great. I kept that image and just uploaded ssl84 and it crashed/rebooted frequently. I figured I should start from scratch, flashing fresh OpenPLi stock followed with ssl84 & still experienced frequent crashes.

I suspect it's an issue with the SSL as OpenPLi has been running great w/ SSL82 & patched tuner driver, online updates & all. It's been a simple image to "patch" since the August driver release, no "expert" needed...

--

I also suspect the SSL has some problems. If an original image with ssl84 also has freezes/reboots it's not likely the fault is in my image build.

Thanks both of you. I just wanted to flash ssl 84 but than I stay with ssl 82. It works perfectly the way what cokesux wrote. Openpli online update every day with ssl 82 and patched driver. So I am waiting for fix ssl84.

I have heard reports that it is also working fine for some, it may work for you. I'd make a backup before playing though, just in case...



--

It works indeed fine for me on my currenlty used PLi, did updated online many times since i freshly installed it back in september, tricked the ssl when they did add on 18 oktober with updating, flashed the ssl today reboot all fine, did replace patched 0902 driver with orginal 0902 all still running stable...

saty said:

It works indeed fine for me on my currenlty used PLi, did updated online many times since i freshly installed it back in september, tricked the ssl when they did add on 18 oktober with updating, flashed the ssl today reboot all fine, did replace patched 0902 driver with orginal 0902 all still running stable...

Click to expand...

It's hopeful :thum: I am in same boat. I have updated image (oct 26) with patched drivers and tricked ssl.
So maybe I can do it what you did.

Hooray! It is working. Only the reboot function is buggy, when I reboot (even if full reboot or just enigma2 reboot), box is going to down black, (oled black, tv screen black) and nothing happen. I can telnet and ftp the box, so it is freezing into reboot methot. I must plug out and plug in again.
But the below method is working for me.

1. I have an openpli with overwritten dvb-modules and secondstage in file /usr/lib/opkg/status (82->84, 110821->110902) and last online updated in oct 26.
This is the base!

2. I restored original value of dvb-modules in status file to 110821

3. Plug out, plug in with power button for ip and flashed patched ssl 84 with webif. Reboot.

4. I made an online update of software (with 30 package, contained dvb-modules) and reboot.
(There was some issues because of this reboot freeze bug, til I realized what it is, and there was an update freeze maybe because of internet issue, so I needed repeat update several times until finished well)

5. Now I have an online updated openpli , working well (with only this reboot freeze issue).

Some thing I don't understand:
Why enigma2 is the only package what shown available any time I make an online update?
There is 1 package update: enigma2
Anytime I make an update it showed as available fresh version of enigma2. Only the enigma2 but this is refreshable all the time. (Even I make update in 5 minutes again)
Never show "no updates, fresh system". Why is that? Or is it normal?

Second thing: I can't discovery any changes with new ssl and dvb-modules. No faster boot, no stronger signals or faster freq searching.
Is there a changelog for 0902 drivers and ssl 84 anywhere? I am interesting what these updates innovate in our system.

Same thing here like "saty" mentioned back there, that is i was running ssl82 on patched 0902 drivers, running updates and everything...only difference for me is that i didn`t replace with original drivers when ssl84 was available for download.

After ssl84 came out, i flashed it first, rebooted to my updated build running "0902 patched" drivers, the new ssl84 seemed to run fine on those too, watched some tv for a quick-and-dirty test, then I flashed gjs`s masterpiece "OpenPLi-2.1-beta-dm800-20111028-sim201-ssl84.nfi"...upon first boot from flash, i experienced "one" freeze and then enigma auto-restarted...with no crashlog.

After second boot from crash everything seems to be running perfectly so far...so what might be the culprit in all that?, i thought maybe it has something to do with restoring all the plugins and settings like "cokesux" suggested because i have autobackup`s autoinstall file inside ...i didn`t give it much thought though because i always used to set it up that way and it always worked...only this time by the way it didn`t restore everything like it used to...i thought it was weird, so i started downloading and configuring the other plugins ...everything is back in place and it`s been running fine from yesterday until now non-stop.

On a side note i updated this morning and rebooted with no problems at all...if there`s a way to force that enigma-ssl-smth else-freeze bug, please report back here so i can try on my end..I`m still testing.

looks like we didn`t have to flash ssl84 prior to flashing with an "already ss84-patched-image" according to mafarj57`s Read-Me on the intro post:

-Flashing already patched images with sim2 ssl84
just flash the image with dreamup or internet explorer method without loading sim2 ssl84 whatever the current ssl version loaded to dreambox.

That might explain it!!!

I created a new image with a NFI1 image layout.
This change is only about the memory layout of the flash, all new functionality is present in this image !
I hope this solves the current problems.

Hi, yesterday I loaded ssl84, then reboot and the original image PLI 2.1, again without rebooting ssl84 after uploading the image .... and, unfortunately, unstable image ...

But again ssl84 upload, via telnet solved my problem comes from a stable image yesterday.
ps: ssl84 install the file. ipk restart and then we have image has fully operating.





sorry for english google translator:

I'm also getting the same thing. Updated to ssl84, rebooted then updated to the latest OpenPLi image, then reflashed ssl84 and my box now just hangs after around 10 minutes and then around a minute later reboots.

I've tried installing the ipk as suggested above but that produces errors, seems to do some sort of update but doesn't fix the problem.

It's still not working well.
Use this one for the time being.

gjstroom said:

It's still not working well.
Use this one for the time being.

Click to expand...

Cheers, tried both the 28 and 29 images but same problems so am going to go back to ssl82 for the time being

I'm now testing the 1029 image with ssl82 and the patched bcm7401.ko. This should work just like the 1023 version.
If it works well we can conclude something is wrong with SSL84.

I also noticed once in my logs, while SSL84 was running, that I have never seen before:

Oct 29 02:04:29 dm800 kernel: JFFS2 notice: (19) check_node_data: wrong data CRC in data node at 0x0318f600: read 0x4f941370, calculated 0xf251e0ea.

Google shows that it might've just been the result of one of the previous crashes:

According to Dave Woodhouse, who wrote JFFS2, these notices typically mean that at some point you've hard powered off, and as a result JFFS has some uncommitted data lying around on flash. It's almost always harmless, a part of the journal which was never committed: "either it was a new write which hadn't yet been synced, or it was a GC write which just doesn't achieve anything now." However, these messages *could* indicate an actual problem -- "we never came up with a good heuristic for when _not_ to complain". Woodhouse suggests that in the future "perhaps we should write a 'yes, I know there's a CRC failure' node _after_ the offending node, when we reboot and find it" since directly rewriting the node is not an option due to the mechanics of NAND flash; that would help confine these messages to immediately after a hard reboot. At present, you'll keep seeing a "bad CRC" message every time that particular JFFS node is accessed until it is eventually GC'ed.

Click to expand...

--

... also I was able to run SSL84 long enough to create a nfibackup last night, which created a nfi1 image of course. I flashed it back today and so far:

up 1:28, load average: 0.09, 0.02, 0.00

Click to expand...

By far the longest I've had ssl84 run in many attempts...

--

I decided to throw an enigma2 restart into the mix because every previous attempt included an enigma restart (forced by restoring settings, or loading channel list, etc...). This image was already configured & running continually since first boot...


Promptly froze after enigma2 restart...

--