Page 1 of 3 123 LastLast
Results 1 to 15 of 33

Thread: vwait Problems with 4.x and 5.x Software

  1. #1
    Join Date
    Nov 2003
    Posts
    291

    Patch for sluggish tivos (caused by vwait bug)

    I posted info about this in another thread a few months ago, but since there are more and more people using v4+, I thought I'd post with the patches, trivial as they are.

    The issue:

    Tivowebplus, mfs_ftp, and other tivosh software rely on a command called "vwait" which is, well not exactly broken, but "damaged" in 4+. It can make some tivos sluggish, especially if both programs are running.

    A solution:

    I've included a tcl patch that, when sourced, will make vwait behave better. I've given instructions where to put the patches for mfs_ftp and TWP, but the patch could be sourced from within ANY tivosh program.


    P.S. If your tivo is still very sluggish after this, especially when running bash, make sure any old kmem, mfs_ftp, and tivoweb lines are commented out in rc.sysinit.author.
    Last edited by BTUx9; 06-24-2004 at 12:32 AM. Reason: change title

  2. #2
    Join Date
    Jul 2003
    Posts
    669
    Quote Originally Posted by BTUx9
    I posted info about this in another thread a few months ago, but since there are more and more people using v4+, I thought I'd post with the patches, trivial as they are.

    The issue:

    Tivowebplus, mfs_ftp, and other tivosh software rely on a command called "vwait" which is, well not exactly broken, but "damaged" in 4+. It can make some tivos sluggish, especially if both programs are running.

    A solution:

    I've included a tcl patch that, when sourced, will make vwait behave better. I've given instructions where to put the patches for mfs_ftp and TWP, but the patch could be sourced from within ANY tivosh program.
    For those that want more info, here is the post that BTUx9 is refering to...
    http://www.dealdatabase.com/forum/sh...ad.php?t=34187

    Thanks BTU....
    Four Hacked HDVR2's,
    One Still slightly confused Hacker,
    4 dogs, 8 cats, and 1 wife that is happy as long as I don't screw up her TiVo ...... Oh yeah two grandchildren that are the light of my life!

  3. #3
    Join Date
    Feb 2004
    Posts
    24
    Thanks BTU. What an impact.

  4. #4
    Join Date
    Nov 2003
    Posts
    291
    The funny thing is: I have 3 dtivos, so I don't even HAVE the vwait bug! I had to ask other people to try the patches for me on their machines.

    I didn't post the patch earlier because I thought the people writing the hacks would implement it, but there haven't been releases recently.

    I'm glad the patch is helping some people.

  5. #5
    Join Date
    Jun 2004
    Posts
    11
    I think I was the first person that Btux had try it. It was a god send.... =)

  6. #6
    Join Date
    Feb 2004
    Posts
    24
    Quote Originally Posted by BTUx9
    The funny thing is: I have 3 dtivos, so I don't even HAVE the vwait bug! I had to ask other people to try the patches for me on their machines.

    I didn't post the patch earlier because I thought the people writing the hacks would implement it, but there haven't been releases recently.

    I'm glad the patch is helping some people.
    How did you even notice the problem?

  7. #7
    Join Date
    Nov 2003
    Posts
    291
    Quote Originally Posted by dishman
    How did you even notice the problem?
    Helped someone monte a 5.x machine. After it was done, it was sluggish and the cpu usage was way off for idle tivosh tasks.

    I did some research and found about the vwait non-problem (the most common reply by the "experts" was that it was an "artifact" of ps/top, and that they were tasks running at "idle priority" (wtf?)).

    So I ran some timing tests, and proved definitively that it was no such thing. That it had a real affect on the tivo's functioning, especially when 2 or more processes were using the broken vwait, because it would cause constant context switches (every timeslice).

    When I posted my findings, ADH backed me up and posted the root cause: in pre-4 versions of tivosh, vwait used a select with a timeout, which causes a context switch, and let other processes run, but in v4+, it has a 0 timeout which returns immediately, so it spins in that loop, using 100% cpu until it is preempted.

  8. #8
    Join Date
    Jan 2002
    Posts
    65
    I've been using this for a while and it seems every once and a while it looses the cache_ vars that are persistant. Tivoweb gives this error:

    INTERNAL SERVER ERROR
    --cut here--
    action_search '' 'set "searchby" "0";set "cat" "0";set "scat" "0";set "q" "blue";set "submit" "Search";'
    can't read "cache_sp_moddate": no such variable
    while executing
    "if {$spmoddate == "" || $spmoddate == $cache_sp_moddate} {
    return
    }"
    (procedure "update_sp_cache" line 16)
    invoked from within
    "update_sp_cache"
    (procedure "::action_search" line 113)
    invoked from within
    "::action_$action $chan $part $env"
    ("eval" body line 1)
    invoked from within
    "eval {::action_$action $chan $part $env}"
    --cut here--

    It takes a halt and restart to fix it.

  9. #9
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    I found that when trying to use the PC media server (here) vwait seems to break the application. Are there any alternate 'vwait patches' that I might try?
    Last edited by blueman2; 11-14-2004 at 02:57 AM.

  10. #10
    Join Date
    Sep 2002
    Posts
    26

    vwait

    Did you try patching tivoapp's polling select call instead? Try changing the last parameter to an absolute pointer to two dwords. The struct timeval is:

    long int tv_sec;
    long int tv_usec;

    So find two words in the process address space (it can even be code) that would do. Something like 00000000 000000f0, which would be about 1/4 millisecond of idle. You could point it at that. Or, you could just patch whatever structure it's passing right now, by either altering its initialization or if its static, patching the data segment.

    Might work better than a substitute TCL vwait.

    -- gd

  11. #11
    Join Date
    Jan 2002
    Posts
    1,777
    Quote Originally Posted by gorilla daddy
    Did you try patching tivoapp's polling select call instead?
    Yes, that's a good idea.

    A few months ago I traced through the vwait code in tivoapp and in the TCL sources. I mapped out the following functions in 4.0:

    e05480 = Tcl_VwaitCmd()
    e3226c = Tcl_DoOneEvent()
    e4ffb0 = Tcl_WaitForEvent()

    I did a little more digging and applied the following patch to force a 1ms delay instead of a zero delay on select():

    4.0: VMA dbb8c8: 10400019 -> 10000019
    5.1.1b: VMA f51fc8: 10400019 -> 10000019
    5.4: VMA 1057348: 10400019 -> 10000019

    I don't do a lot of TCL programming so I'm still not sure if it breaks anything, but the "mainstream" stuff (TWP, mfs_ftp, etc.) seems to work okay and no longer hogs the CPU. YMMV.

  12. #12
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    Quote Originally Posted by alldeadhomiez
    Yes, that's a good idea.

    4.0: VMA dbb8c8: 10400019 -> 10000019
    ADH, I am new to patching and would appreciate some guidance. I opened my Tivoapp in a hex editor, and looked at location 9bb8c8, (taking 400000 from VMA for MIPS system to get hex offset) but did not see the data value you listed (104000019). I see 8F393638.

    I did see 10400019 at 9BBABA, but not sure if that is it.

    What am I missing?
    Last edited by blueman2; 11-14-2004 at 03:21 PM.

  13. #13
    Join Date
    Aug 2003
    Posts
    2,149
    Quote Originally Posted by blueman2
    ADH, I am new to patching and would appreciate some guidance. I opened my Tivoapp in a hex editor, and looked at location 9bb8c8, (taking 400000 from VMA for MIPS system to get hex offset) but did not see the data value you listed (104000019). I see 8F393638.

    I did see 10400019 at 9BBABA, but not sure if that is it.

    What am I missing?
    Well what you're missing is a 4.0 binary .

    Just kidding. You have a 4.0.1b tivoapp. As you said, 8F393638 is at 9bb8c8. Although the 10400019 you mentioned starts at 9BBABC.

    Your math is correct.

    I've just confirmed that the 4.0 location is correct as posted by alldeadhomiez. I'll look into the 4.0.1b locations also.

    I'm wondering if I have this vwait problem. My speed seems ok. Maybe I'll patch it and see if I notice a difference.

    [EDIT] This patch works fine and reduces cpu utilization a lot.
    Code:
    4.0.1b: VMA dc1aa8: 10400019 -> 10000019
    NutKase
    Last edited by NutKase; 11-28-2004 at 03:35 PM. Reason: clarity
    "God, and DealDataBase, help those that help themselves." --Shamelessly stolen from psxboy
    ------------------------------------------------
    2 each, SA S2 287hr 7.2.1a's with Lifetime.
    Hacks: 1 Manually Monte'd -140, Bash,Telnet,FTP,TivoWebPlus,
    Superpatch-67all Unscrambled/HMO,MFS_FTP Ver. N,TyTools, tivoserver
    Fully hacked SA S1

  14. #14
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    Doh! Yes, I just figured it out too! 61E0 offset from 4.0 to 4.01b in that area of the code.

    Thanks!

  15. #15
    Join Date
    Jul 2004
    Location
    California
    Posts
    298
    Yes, this patch appears to work!!! CPU utilization is just as good as when I was using the vwait tcl patches listed at the start of this thread. Thanks Gorrilla Daddy, ADH, and NutKase!
    Last edited by blueman2; 11-14-2004 at 04:24 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •