1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Fixes for MFSTools 2.0 swap problems

Discussion in 'TiVo Upgrade Center' started by Robert S, Jul 31, 2002.

  1. Aug 2, 2002 #21 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    Originally posted by mtg101
    As mentioned above, I'm planning on replacing my drive with a single 120GB A drive. Would it be useful to people if I tried it first with MFSTools 2.0 to see if I get the swap problem?

    Yes please! Start by trying to replicate Cpen's upgrade, if that works reliably I'll have to rewrite the top post in this thread.

    To be a worthwhile test you must ensure that hdx8 doesn't contain a valid swap partition. Obviously the first time the disk will be blank, but on subsequent attempts, dd hdx9 onto hdx8 to make sure it's corrupt.

    I'm sure you really just want to get your TiVo working, but if you want to try some variation, I would be interested to see if it makes a difference if MFS Tools runs in a byteswapping environment.
     
  2. Aug 2, 2002 #22 of 609
    BareMetal

    BareMetal New Member

    4
    0
    Jul 16, 2002
    I've worked on three series 2 standalone systems. Two of them i used the -s 128 option on the third one I didn't. The first two have no swap, but the third one does.
     
  3. Aug 2, 2002 #23 of 609
    sdunne

    sdunne New Member

    43
    0
    Jul 6, 2002
    I've just moved from a single drive UK model Tivo (Thompson 6020 series) to dual 160Gb Maxtors. I followed the Hinsdale guide, in particular:
    Step 7 Option 1) (but backing up to a linux partition) via "mfsbackup -l 32 -6so /mnt/rh73/TivoBackup /dev/hdc"
    Step 8 via "mfsrestore -zpi /mnt/rh73/TivoBackup /dev/hdb
    Step 10 Upgrade Configuration #3 via "mfsbackup -Tao /dev/hdc | mfsrestore -xzpi - /dev/hda /dev/hdb"

    It all seems to have gone ok. System Info is reporting 94 hours 27 mins best quality (330 hours 19 mins in basic).

    I checked my kernel logs and it looks like a new 64Mb swap partition was created, one message in there "Adding Swap 65532k swap-space (priority -1)" suggests.

    It's since been rebooted without any apparent problems.

    Fingers crossed, but leaving out the -s 128 seems to have worked out OK

    Stephen
     
  4. Aug 3, 2002 #24 of 609
    klincoln

    klincoln New Member

    3
    0
    Aug 2, 2002
    Washington, DC
    On Thursday, I successfully upgraded a previously upgraded SA Sony SVR-2000 with MFSTools 2.0. This TiVo began life as a 30hr single drive unit running 1.3 with a locked Quantum 30GB drive. During the "1.3 era", BlessTiVo was used to add a 60GB Maxtor B drive and expand the unit to roughly 100 hours. It ran in this configuration, with OS upgrades along the way to 3.0, until I saw MFSTools 2.0 and 160GB Maxtor drives for $169 at a local computer show.

    The upgrade scenario was Hinsdale's UPGRADE CONFIGURATION #5: Any Dual Drive TiVo to New A and New B Drive (replacing both drives), Option #1 MFSTools single step method using four IDE ports and the MFSTools 2.0 boot floppy. The existing drive pair were reasonably full, using 81GB out of an available 91GB. The two 160GB Maxtor upgrade drives were virgin, fresh out of the shrink wrap. No byteswapping was used. The anecdotal evidence so far seems to point towards the -s option being the root of the swap partition problems. Based on this, the -s option was omitted from the MFSTools command line. The following command was used:

    mfsbackup -Tao - /dev/hda /dev/hdb | mfsrestore -xzpi - /dev/hdc /dev/hdd

    81GB and 21 HOURS LATER (!), after successful completion of the backup/restore, the new 160GB A and B drives were installed in the TiVo. The unit booted and operated properly. Backdoor inspection of the kernel log confirms that a properly initialized 64MB swap partition is activated:

    "activating swap partitions"
    "adding swap:65532 swap-space (priority-1)"

    Since Thursday, I've booted the unit about a half-dozen times, with the swap partition successfully activating each time. All TiVo functions work properly and reasonably promptly. All menus are properly populated and all migrated recordings play correctly. New recordings work fine at all compression levels. Recording capacities are as expected, ranging from 94.5 hours at best quality to 344.5 hours at basic quality. "Save Disk Space" (VBR) is disabled.

    My experience would seem to lend support to the growing evidence that MFSTools 2.0 can create a working swap partition provided you don't try and grow the swap partition via use of the -s option (64MB swap partition correctly created on a virgin drive in this case with the -s option omitted). My gut feeling is that this unit would also successfully complete an mfsfix if it suffered file system corruption and a GSOD. I feel that those MFSTools 2.0 upgraded units that are suffering signal 11 exceptions during mfsfix also don't have a properly initialized swap partition because they used the -s option during their upgrades. If someone can supply more info on using mfsassert to trigger mfsfix, I'd be more than happy to test this hypothesis.

    Kevin
     
  5. Aug 3, 2002 #25 of 609
    DCIFRTHS

    DCIFRTHS I dumped SDV / cable

    2,119
    0
    Jan 6, 2000
    New York
    klincoln: Very nice report. It's easy to read with great attention to details. Welcome to the forum.
     
  6. Aug 4, 2002 #26 of 609
    jhburke

    jhburke New Member

    5
    0
    Aug 3, 2002
    Darien, IL
    I just spent the last few hours trying to fix the swap on my DirecTiVo 2.5.2 which I upgraded about 5 weeks ago using MFStools 2.0 and the 128M swap option (which of course resulted in an unusable swap partition). I have an old 2 drive Philips DTivo and I upgraded to 2 new Maxtor 120GB drives, preserving all the old recordings. I really haven't noticed any problems despite the lack of swap, but I thought I would try to fix it anyway to try to avoid GSOD...

    1. I first tried using the MFStools 2.0 boot CD to run mkswap. The byteswapping option on boot is bad; you have to manually type in "vmlnodma hdb=bswap hdc=bswap hdd=bswap" at the boot prompt to use byteswapping. I ran mkswap /dev/hdc8 without errors ("131xxxK bytes"). I ran swapon /dev/hdc8 and checked /var/log/messages ("Adding swap-space 131064K (priority -1)"). However, when I put it back into the DTiVo, the swap was not used with the same errors.

    2. Then I tried using the DTiVoMad boot CD (which does byteswapping by default). Same process, same results - swap partition works in the computer, but not back in the DTiVo.

    3. Now I tried to copy the swap partition from my original TiVo A drive to the upgrade drive ("dd if=/dev/hdd8 of=/dev/hdc8"). I know this is only a 64M swap file copied to a 128M swap partition, but I figured "why not?!" since I couldn't think of anything else except to reupgrade and wipe out the last 5 weeks of recordings. It showed no errors, and swapon /dev/hdc8 gave a successful message in /var/log/messages (Adding swap-space 65332K (priority -1)). Now, back in the DTiVo and voila!, I now have a functioning 64M swap file, according to both /var/log/kernel and /var/log/messages via backdoors.

    Now, what to think?

    Will having a 64M swap file in a 128M swap partition cause problems down the road? So far, so good. I can't tell any difference with the speed of menus or Now Playing list, however.

    Maybe MFStools 2.0 initializes the swap file correctly (I never tried to mount it from the computer before running mkswap the first time) but DTiVo cannot use a 128M swap file. This doesn't seem entirely true since in an older swap problem thread someone was able to initialize a 128M swap file by running mkswap from the rc.sysinit file in a stand alone TiVo.

    Anyway, just posting my results. I'll let everyone know if I find any problems with my current fix.

    John
     
  7. Aug 4, 2002 #27 of 609
    klincoln

    klincoln New Member

    3
    0
    Aug 2, 2002
    Washington, DC
    Thanks DCIFRTHS. I've been a long time lurker who has sponged volumes of valuable information from the generous folks around here each time I've gone thru one of my flurries of TiVo upgrade madness.

    To add to yesterday's post, I supposed that an MFSTools 2.0 upgraded TiVo that had a confirmed working swap partition would subsequently complete an mfsfix/GSOD. I was seeking advice on mfsassert to test the theory. Well, I can now report that theory is ONE HUNDRED PERCENT WRONG! After yesterday's post, I put a bash shell up on the serial port via rc.sysinit.author, fired up tivosh, and executed "mfsassert -please" out of /tvbin. The shell console confirmed "MFS filesystem has been marked inconsistent" among the spew from several unhappy threads as the system rebooted...to the desired (?) GSOD. After roughly three or four minutes, it once again rebooted back to the GSOD. While watching this second reboot sequence I was already taking the side off of the PC, and rummaging for the previous A and B drives and my spare IDE cables. I allowed it to continue this reboot/GSOD cycle for roughly an hour before putting it out of its misery. Upon mounting the "dirty" A drive on the PC, the kernel logs confirm repeated signal 11 failures in mfsfix.

    So, in my case, even though the swapfile was properly created, the MFS partitions/data were layed down by MFSTools 2.0 in some fashion that indeed gives mfsfix heartburn.

    Deciding to copy my original 100 hour configuration back to the new pair of drives again with MFSTools 2.0 and keep recordings, rather than revert to MFSTools 1.1, I looked a little more closely at the MFSTools 2.0 boot floppy environment. My first (21 Hour!) backup/restore was done with byteswapping enabled/DMA disabled (duh)! My comment of yesterday regarding the original backup/restore being done without byteswapping was wrong. My limited Linux skills get lightly sharpened during my TiVo flurries, but then WAY too many sleep periods elapse between uses. After using "hdparm -d1 /dev/hdx" to enable DMA on all four drives, the 81GB backup/restore takes about 90 minutes! This new configuration also worked correctly in all operational respects. And, since this configuration really did result from a non-byteswapped backup/restore environment, I executed the mfsassert command again for the sake of posterity. Been there, done that, same story. The problem with MFSTools 2.0 MFS partitions and mfsfix is not influenced, in my case, by whether the backup/restore environment is byteswapped or not.

    Knowing that I can restore it in less than two hours, I'll continue to run this MFSTools 2.0 config with migrated recordings while I wait for a solution to the mfsfix issue. I'll take my chances against a legitimate GSOD until then. Like most of us, I'd be nowhere without these superb tools that are created by people like Tiger. They've MADE my TiVo experience. I'm confident the problem will be corrected.

    A TiVo weekend in the A/C from a blistering Washington, DC...

    Thanks,
    Kevin
     
  8. Aug 4, 2002 #28 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    klincoln, if you're in the mood to experiment, would you like to try MFS Tools 2.0 with -r 0 (1 Mb block size)? Some people have expressed the hope that this might create a recoverable TiVo, but no-one's tested it.
     
  9. Aug 4, 2002 #29 of 609
    jhburke

    jhburke New Member

    5
    0
    Aug 3, 2002
    Darien, IL
    I had an additional thought about the bad swap files:

    I never used TiVoMad to upgrade before, but I understand there is an option to expand the swap file when the combined hard drives are greater than 140 GB to help prevent GSOD from mfsfix. I wonder if someone could provide an image of a good 128MB swap file, which I (and others) could dd onto our mfstools 2.0 expanded swap partition to get a good 128MB swap file. This will be even more important if the 1 MB block size mfs partitions (which might not break mfsfix) is the answer to prevent mfsfix errors, because with the small block size and only 64MB swap, mfsfix will run out of memory. My understanding is that it is not possible to get a bash prompt or to edit rc.sysinit on a DTiVo, so this might be the only way to get a good 128 MB swap. Unless, of course, we fall back to mfstools 1.1. Of course, I guess I could get another blank drive, use the old tools, get a good 128MB swap file, and then dd it to my current upgrade. I just might try that next time I have time (maybe next weekend).

    John
     
  10. Aug 4, 2002 #30 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    That's not a bad idea. If you start with a blank disk, or zero the partition out (use dd to copy /dev/zero over the partition) before running mkswap then a gzipped copy would be tiny. It may well be that any 128Mb swap partition would be a suitable source (subject to byte-swapping considerations).
     
  11. Aug 5, 2002 #31 of 609
    klincoln

    klincoln New Member

    3
    0
    Aug 2, 2002
    Washington, DC
    Robert S, trying the -r 0 crossed my mind as, under the circumstances, MFST2's default larger block size is a strong suspect in my mind for the cause of mfsfix's heartburn. However, given that I want to confine my testing to a 2x137GB target with preserved recordings, I'm hesitant to invest the time to test -r 0 without the known ability to lay down a valid 128MB swap partition to accompany -r 0's smaller block size on this >140GB configuration. Just as jhburke is creatively mulling the same dilemma, I'm in search of a solution. Without a valid 128MB swap partition, I don't hold out much hope for -r 0.

    I'll see what comes up between now and next weekend, and maybe give it another whirl then.

    Kevin
     
  12. Aug 5, 2002 #32 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    Hmm, swap partitions, it really shouldn't be that hard to make them, you know?

    I think the swap partition on a TiVo is just the same as any swap partition on any Linux system. If this is true, then the following should work:

    Boot any normal Linux install (I used Tom's Root and Boot Disk as it's a convenient single-disk Linux.

    Create a blank file of the right size. I did

    dd if=/dev/zero of=/mnt/swapfile bs=1024k count=128

    (obviously you'll need something mounted on /mnt to take the file).

    swapfile is 134,217,728 bytes long. Is this the right size for a 128Mb swap partition?

    Then

    mkswap /mnt/swapfile

    I then did

    gzip /mnt/swapfile

    and it created swapfile.gz at 131kb.

    Now, I'm not sure that file is the right size to copy onto your swap partition, so you might want to try the following:

    From a swapping environment:

    dd if=/dev/hdx8 of=/mnt/swapfile

    From an environment where you have a mkswap command available (Tom's would do nicely)

    mkswap /mnt/swapfile

    and then from a swapping environment

    dd if=/mnt/swapfile of=/dev/hdx8

    If this works (I have no easy way to test it) you could gzip swapfile and post it for others to use. If swapfile doesn't compress well, once you know the size of the swap partition you could use dd as above to create a file the same size made of zeros (bs=1 count=<filesize>), run mkswap on that and then gzip it.

    This is not a risky procedure, as long as the swap file is no larger than the swap partition you won't overwrite anything - the worst than can happen is that the swap won't activate at boot.
     
  13. Aug 5, 2002 #33 of 609
    rswift

    rswift New Member

    7
    0
    Mar 5, 2002
    Overland...
    I, too, am suffering the invalid swap file after using the -s 128 option in the MFSTools 2.0 boot CD. I have a Sony T60 with a Maxtor 160G A drive + Maxtor 80G B drive. Reported recording time is 204 hours, and has been working fine for a couple of weeks. After checking the threads here, noticed the swapfile issue, enabled back doors, and discovered the problem.
    My quandry/question is whether to do anything now, or wait until:
    A) My DirecTiVo crashes, then I take the original 40G Quantum and re-upgrade, or
    B) Some genius figures out how to create a 128Mb swapfile usable by TiVo with support for fsfix.

    Is it worth trying to copy the 64Mb swap file from my original drive onto the new A drive into the 128Mb partition?
    I'm not sure I understand the risk of running without a swapfile, vs using a 64Mb swapfile in my 204 hour TiVo. Can 64Mb swap handle a TiVo with less than 140Gb? If so, maybe I should downgrade to just the single 160G Maxtor. I haven't read anything so far that pinpoints the cause of the fsfix, sigma 11 error, but something gave me the impression that may be related to having insufficient swapfile space for large capacity TiVos.

    Thanks to all who've made the upgrades possible. The added capacity is well worth any hassles in opening the box and copying the drives.

    rswift
     
  14. Aug 5, 2002 #34 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    The swapfile issue and green screen recovery aren't linked in your case. It is true that increased swap space is necessary for earlier versions of MFS Tools and earlier versions of TiVo OS, that no longer applies.

    There is currently no known way to make a TiVo that can recover from green screen if it's been upgraded with MFS Tools 2.0.

    Copying your 64Mb swap partition from your old drive is a good solution for now. (Unless you'd like to try the swap file method I posted just above you, that post was written with some Linux knowledge assumed, I can explain it more carefully if you're interested.)

    If you want a 'safe' TiVo (ie, green screen recovers) you will have to repeat the whole upgrade with pre-MFST2 tools - or wait for a fix for MFST2 problems.
     
  15. Aug 5, 2002 #35 of 609
    rswift

    rswift New Member

    7
    0
    Mar 5, 2002
    Overland...
    Any guess as to the issues with running without ANY swapfile?? Everything seems to be working with no issues right now. Maybe it's because I haven't let the new drives start getting really full yet. My assumption would be that the swapfile might become very important as the lists of Now Playing, Season Passes, etc. start growing very large, and TiVo needs more memory space to play with the lists??
    Thanks for the offer. I've not played with Linux at all, and have limited knowledge of UNIX, mostly Solaris. My first inclination is to dd the old swapfile into the new swap partition.
    One thought I had is that if the new swap partition created with the -s 128 option is just slightly too small, even by a byte or so, will a properly created 128 Mb swapfile necessarily fit into the space? Not knowing exactly what the -s option really did, it's hard to predict. In my gut, I fully expect to have to re-upgrade using my old 40Gb original TiVo disk, so I've been copying to VCR most of my "must save" shows. YUK!~
    Thanks for the help.
    ~rswift
     
  16. Aug 5, 2002 #36 of 609
    Robert S

    Robert S New Member

    9,725
    0
    Jul 8, 2002
    Cambridgeshi...
    It appears that the problem with the missing swap relates to the program guide functions rather than the recording/playback functions (which are mostly handled in hardware). On UK TiVo's the missing swap prevents TiVo from making daily calls, on US machines it just seems to slow everything down (~24hour indexer runs).

    On the space issue, my suggestion above was to dd the current swap partition to a file on your hard drive, therefore when you copy it back it will be precisely the right size. It would be nice if you could validate that, but copying your 64Mb swap partition over would make your problems go away very safely.
     
  17. Aug 5, 2002 #37 of 609
    rswift

    rswift New Member

    7
    0
    Mar 5, 2002
    Overland...
    I may have to wait until next weekend to play with any of these new ideas. I took the day off work today, but can't do that again for a bit. Let's hope a real fix to this, and the GSOD problem are discovered and posted soon. I'm a bit nervous now.
    On an unrelated note, I've had smoke coming out of my TiVo on two occasions, yet the thing still lives on! I fried the original TiVo Quantum drive while copying it the very first time. One of the IC's on the IDE circuit board glowed white hot and smoked out. Thought it was toast, but replaced the little circuit board on the back of the drive with one off of a new spare Quantum, and darned if it didn't come back to life. Then, I smoked the motherboard while replacing the internal fan (trying to make TiVo run cooler) and while the fan supply got fried (I now use power from the 4pin hard drive connectors) the TiVo still lives.
    Needless to say I open the cover of my T60 with much trepidation...
     
  18. Aug 6, 2002 #38 of 609
    BareMetal

    BareMetal New Member

    4
    0
    Jul 16, 2002
    My experience with no swap, is a series 2 tivo that starts shutting down services and leaves me with a grey screen every other day. I just need to find some time to fix it..
     
  19. Aug 6, 2002 #39 of 609
    Ivor

    Ivor New Member

    13
    0
    Aug 5, 2002
    Middlesex UK
    Robert S said:

    "swapfile is 134,217,728 bytes long. Is this the right size for a 128Mb swap partition?"

    From http://www.mcc.ac.uk/Documentation/linux-doc/LDP/sag/x1762.html:

    "The Linux memory manager limits the size of each swap space to about 127 MB (for various technical reasons, the actual limit is (4096-10) * 8 * 4096 = 133890048$ bytes, or 127.6875 megabytes). You can, however, use up to 8 swap spaces simultaneously, for a total of almost 1 GB.

    With newer kernels and versions of the mkswap command the actual limit depends on architecture."


    Could this be the cause of the problem, i.e. MFS2 *is* creating a 128Mb swap file/partition, but TiVo is unable to recognize it because of kernel/hardware limitations?
     
  20. Aug 6, 2002 #40 of 609
    enigma2175

    enigma2175 Long Member

    63
    0
    Apr 1, 2002
    From the mkswap man page:
    It sounds like the tivo kernel is new enough to use 2 bytes per page, and that swap partitions can be up to 2 GiB. Maybe I'm wrong, and who knows what TiVo did to the kernel, but I think we're safe in that regard. However, it might be wise to create 2 64MB swap partitions and use them both (or even better, have one on your second disk, better performance.)
     

Share This Page