Click here to go to the forum index Click here for the home page
 
Author Message

<  Bugs  ~  Don't run too many TAPs!

Page 1 of 2
Goto page 1, 2  Next
R2-D2
Posted: Tue Aug 21, 2007 8:32 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
FireBird has just informed me of a bug related to running TAPs. If you run a lot of TAPs and exit them, the system does not properly free a disk resource. Eventually this resource is exhausted (there are 32 slots available, although a few are taken by other Toppy activities). and some routines do not trap this error, leading to a crash on disk access. I've seen this with USB connections after running lots of test TAPs, but it can also cause the next TAP you run to crash when it tries to use the disk.

I suspect this issue is of prime concern to developers who run and exit a lot of TAPs. I'm sure a fix will be made available, but at the moment this might help explain some of the strange crashes you get.
View user's profile Send private message Visit poster's website
R2-D2
Posted: Tue Aug 21, 2007 10:01 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
The fix appears to be a little easier than I'd thought (thanks to the awful compiler that produced the firmware routines). For those who are interested, here's a firmware patch.

Before the patch, my Toppy has 17 slots free after booting. After the patch I have 20. Before the patch, doing something like running and exiting, say, RecordingFixer 18 times would be fatal.
View user's profile Send private message Visit poster's website
glenmcfar
Posted: Tue Aug 21, 2007 10:09 pm Reply with quote
Frequent contributor Joined: 07 Dec 2006 Posts: 4519 Location: Dundonald, Ayrshire, Scotland
Fatal Shocked

By jings....

Glen.

_________________
H/W: TF5800 | URC-7555 | Asus | Best Firmware Ever!
A/S: SecCacheUK, EitSub, EPG2MEI, Display, Extend, QuickJump, FontManager, TapLauncher, MyStuff
T/L: TapCommander, Surfer, MeiSearch, MediaManager | HDFW, CutAds, Sudoku
View user's profile Send private message
underquark
Posted: Tue Aug 21, 2007 10:37 pm Reply with quote
Frequent contributor Joined: 06 Oct 2005 Posts: 1790
Do these slots get re-allocated when the Toppy goes into standby or is the attrition permanent until full power off and re-boot?
View user's profile Send private message
R2-D2
Posted: Tue Aug 21, 2007 10:55 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
underquark wrote:
Do these slots get re-allocated when the Toppy goes into standby or is the attrition permanent until full power off and re-boot?

That's a good point! Going to standby resets pretty much everything, including these slots. But people who leave their Toppys on 24 hours a day will clearly run into this problem more often than other users.

Since FireBird pointed it out I can remember getting seemingly random crashes when testing a TAP. I would transfer the TAP using ftp, run it, fix it (Smile), transfer it again, etc. Occasionally the Toppy would go pfft when I started the ftp transfer on the nth try.
View user's profile Send private message Visit poster's website
charley
Posted: Tue Aug 21, 2007 11:25 pm Reply with quote
Frequent contributor Joined: 13 Jul 2005 Posts: 1563 Location: Belfast
Thanks for the patch R2-D2. Perhaps a reference to it in Firmwares, enhancements and upgrades would lead others to it.

_________________
regards Charley
Toppy: TF5800PVR250GB &300GB;Firmware: ; Remote: Harmony 655; Tx:Divis; Autostart TAPs: MEISearch 1.35, MyStuff 6, AutoReboot V2.2, epg2mei, Power Manager v2.0, TAP Commander 1.2, TF5000 Display v1.50, MHEG_State; Other:
View user's profile Send private message
andyrogers
Posted: Tue Aug 21, 2007 11:35 pm Reply with quote
Frequent contributor Joined: 07 Dec 2005 Posts: 814
Thanks for yet another patch R2-D2 for making the toppy even more stable(ish).
I currently now have got my firmware patched with 9 patches.
So what letter should be used with this patch then for a description??

Andy

_________________

Firmware: 5.14.09 Patched
AutoStart Taps: MyStuff v5.52b, eit2mei beta 7.8m7, , Power Manager v1.2, Tap Commander v1.32, TF5000 Display v1.53a, Discription Extender v2.3, SDS 1.3b, QuickJump 1.72
Other Taps: Sudoka, mei2archive, mei2eit, snake, meisearch
View user's profile Send private message
underquark
Posted: Tue Aug 21, 2007 11:55 pm Reply with quote
Frequent contributor Joined: 06 Oct 2005 Posts: 1790
andyrogers wrote:
So what letter should be used with this patch then for a description?

Probably moving out of English, through Greek and into Klingon or something.
View user's profile Send private message
jumbo
Posted: Wed Aug 22, 2007 4:57 am Reply with quote
Frequent contributor Joined: 11 Apr 2005 Posts: 4731
Let me see if I have got it right: This does not apply to TAPs resident in memory and invoked many times but to TAPs (not necessarily the same) that are loaded and unloaded several times.

So if I have 20 different TAPs and I load and unload each one once only, then I should see this problem somewhere along the way... My firmware is so patched it'll soon be an infirmware Cool
View user's profile Send private message
R2-D2
Posted: Wed Aug 22, 2007 7:13 am Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
jumbo wrote:
Let me see if I have got it right: This does not apply to TAPs resident in memory and invoked many times but to TAPs (not necessarily the same) that are loaded and unloaded several times.

There's a limit on the total number of TAPs you can have running at the same time (16). But every time a TAP runs it uses up one of these 32 available slots -- and it wasn't being released when the TAP exited. Other things make use of these slots, too, so you haven't got the full 32 available to TAPs. When the slots are full, some parts of the system (including loading another TAP) do not cope and this will cause a crash when it next does a disk access.
Quote:
So if I have 20 different TAPs and I load and unload each one once only, then I should see this problem somewhere along the way...
Loading and unloading the same TAP 20 times will have the same effect, and lose 20 slots.
View user's profile Send private message Visit poster's website
simonc
Posted: Wed Aug 22, 2007 3:22 pm Reply with quote
Frequent contributor Joined: 12 Apr 2005 Posts: 5640 Location: Cheltenham
Good grief, more patches! Nice find though. While you're in the general area, is there anything you can do about the 512 byte TAP size problem?
View user's profile Send private message Visit poster's website
dvbgeek
Posted: Wed Aug 22, 2007 3:55 pm Reply with quote
Frequent contributor Joined: 16 Apr 2007 Posts: 168 Location: Sweden
Is this a general patch for most Toppy models (can I safely apply it to the TF5700 firmware, for example, and are all models affected by the bug?)?

_________________
Model: TF5700PVRt HDMI (ID 13426) / Firmware: 2.84 with recommended patches

Autoload TAPs: Power Down / TF5000Display / eit2mei - mei2archive - DescriptionExtender / MyStuff / TAP Commander (always the latest version of everything)
View user's profile Send private message
R2-D2
Posted: Wed Aug 22, 2007 4:13 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
dvbgeek wrote:
Is this a general patch for most Toppy models (can I safely apply it to the TF5700 firmware, for example, and are all models affected by the bug?)?

If the patch fits... wear it. (Arr, jim lad.)

I was surprised how similar the various firmwares were in this area, so the matching is really pretty specific (so unlikely to cause a problem).
View user's profile Send private message Visit poster's website
R2-D2
Posted: Wed Aug 22, 2007 4:50 pm Reply with quote
Frequent contributor Joined: 18 Dec 2006 Posts: 12148
simonc wrote:
Good grief, more patches! Nice find though.
I think FireBird narrowed down the seemingly random circumstances to something that had a hope of being traced. I kept putting it down to something my current test TAP had done, and so hadn't even bothered to mention it to anyone...
Quote:
While you're in the general area, is there anything you can do about the 512 byte TAP size problem?
The specific loading could be fixed, but I'd prefer to fix the root cause: HDD_Flen (and thereby fix all the other routines that use it). Last time I looked at it, it seemed like a relatively straightforward change, but doing so will then break all the TAPs which uses fixed APIs to compensate. And of course a TAP can't just assume that the firmware has been patched.

So I think a good compromise might be to transition the current TAP API fixes to routines that check a dummy TYPE_File to see if the firmware routine reports the correct value and switch over to using their own fix if it doesn't. The logic behind this is that if Topfield ever do fix it themselves then we'll be in the same position (the current TAP API fixes will break).
View user's profile Send private message Visit poster's website
simonc
Posted: Wed Aug 22, 2007 4:53 pm Reply with quote
Frequent contributor Joined: 12 Apr 2005 Posts: 5640 Location: Cheltenham
Topfield probably won't ever change the firmware for bugs like this. I asked them 2 years ago to address the TYPE_Event description truncation, but of course they can't really change it without breaking existing TAPs.
View user's profile Send private message Visit poster's website

Display posts from previous:  

All times are GMT + 1 Hour
Page 1 of 2
Goto page 1, 2  Next

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum