S3 rebooting every 20 minutes

[Jamie]

okay. It is kind of strange, and is probably an artifact of how jmfs works - expanding using a single partition instead of two. Hard to say whether it is the root of your problems.

[unitron]

Hey, Soapm

If you don't have any shows on that 1TB in the S2 DT that need saving, try this.

If any of the drives involved are Caviar Greens, run wdidle3 to disable Intellipark.

Make sure you've got a good backup of the S2 image so you can restore it to the 1TB when you've finished using it as a middleman.

Copy the S3 original drive to the 1TB.

If using MFS Live

backup -Tao - /dev/sda | restore -s 999 -pi - /dev/sdb

If using WinMFS, use the swap size box and put in 999

Then shut down and remove the original S3 drive

Boot into Windows, open WinMFS, select the 1TB and expand.

That should give you 15 partitions, 6 MFS pairs, with nothing left over for pdisk to call Apple Free

Test the 1TB in the S3, make sure it's going to behave itself

After a day or two if no problems, use jmfs to copy the 1TB to the 2TB (it'll take forever), then use jmfs to expand.

That way you wind up with plenty of swap space and no partition over 1.1TB (1.0TiB).

Should be more stable.

[Soapm]

If this one fails in a few weeks I will sure give that a try unitron. Seems like it might work and it would give me a way to increase my swap partition.

I had thought of expanding it twice but I didn't know if jmfs would create an extra partition less than 1TB or would it simply expand the existing partition. You can see where I tried that in post 15 using WinMFS but it created a 16th partition that wasn't usable.

[Soapm]

okay. It is kind of strange, and is probably an artifact of how jmfs works - expanding using a single partition instead of two. Hard to say whether it is the root of your problems.

Thanks, we'll see what happens in a few weeks...

[unitron]

If this one fails in a few weeks I will sure give that a try unitron. Seems like it might work and it would give me a way to increase my swap partition.

I had thought of expanding it twice but I didn't know if jmfs would create an extra partition less than 1TB or would it simply expand the existing partition. You can see where I tried that in post 15 using WinMFS but it created a 16th partition that wasn't usable.

For some reason, expanding with the MFS Live cd results in some extra space at the end, which jmfs sees as a partition. I tried it a bunch of times with different values for the swap partition, but always wound up with a 16th Apple Free partition. WinMFS manages to not leave that little bit of extra, at least when I used 999 for the swap size. That means jmfs can add a 16th partition (which the TiVo will happily accept) instead of a 17th, which the TiVo (which has a 16 partitions per drive limit) interprets as an external drive which needs divorcing, which means you lose the the extra 1-ish TB that jmfs just added.

[Soapm]

It would be nice as Jamie suggested if WinMFS made partition 14 then jmfs made partition 15 and the apple free left over space was partition 16.

I believe that arrangement would be a little more acceptable to the Tivo...

By the way, what does swap size 999 do? I think I used 256 when I to load the truncated stock image directly to the 2TB which seemed to work until the drive began to fill then I started getting the reboots...

[lrhorer]

By the way, what does swap size 999 do?

It gives you a swap partition just under 1G in size.

[unitron]

It would be nice as Jamie suggested if WinMFS made partition 14 then jmfs made partition 15 and the apple free left over space was partition 16.

I believe that arrangement would be a little more acceptable to the Tivo...

By the way, what does swap size 999 do? I think I used 256 when I to load the truncated stock image directly to the 2TB which seemed to work until the drive began to fill then I started getting the reboots...

First of all, jmfs was written for the S4 platform, the Premiere, and just happens to work for the S3 HD (and, I assume, the S3 HD XL), but apparently doesn't work for the original S3. I have no idea why or why not. I am the caveman who has discovered a timetraveler's flashlight and figured out by trial and error how to work the switch, and even that it only works if the batteries are in it and turned a certain way, but has no understanding of how a Le Clanche cell derived battery works--but has decided for the time being not to break one open to investigate further, but to leave well enough alone as long as it gives light.


WinMFS and MFS Live (and the old MFS Tools) add MFS partitions in pairs, just like TiVo originally did. So with your average stock TiVo drive you already have 2 MFS pairs, 10-11 and 12-13. The pre-jmfs tools add the 14-15 pair. That's not the problem. Apparently whatever's available to read and write Apple Partition Maps considers any unpartitioned space to be a partition of the type Apple Free and jmfs wasn't written to take that into account.

So what you need is for whatever creates partitions 14 and 15 to not leave any unused space. That way when jmfs creates a single partition it will be the 16th, and that will be under the 16 partitions per drive limit that TiVo observes/expects/demands.

There are two other separate questions.

Is the original 128MB swap partition size big enough when you go to a bigger drive?

Apparently in the old Series 1 drive embiggening days it was discovered that the TiVo could get into difficulties, getting out of which required using the swap space, and with a larger the replacement drive you needed more, that the original size was no longer enough and just left you stuck in an endless loop.

The rule of thumb that was developed was 1MB for every 2GB of drive size. That's only one twentieth of one percent.

I don't know if the TiVo still needs that much swap space when it encounters whatever situation it is that calls for the most swap space available that will ever be needed, but I figure one twentieth of one percent is cheap insurance.


The other question is how well TiVo deals with partitions of over 1TB, or 1TiB, in size. There seems to be some question about that so I figure if I go from the 160GB to a 1Tb with the traditional tools, and then use jmfs to copy that to a 2TB and create that 16th partition on the second TB, I avoid the problem if there is one.


It's been my experience so far that I can copy the 160GB original to a larger drive, possibly making the swap partition larger in the process, with either the MFS Live cd or WinMFS, but if I do the expand (adding partitions 14 and 15) with the MFS Live cd, there's always a little unused space at the end, which screws jmfs, but that if I do the expand with WinMFS it manages not to leave any left over, so I don't get the Apple Free partition at the end, or elsewhere.

I experimented with various numbers in the neighborhood of 1000 trying to get a 1GB swap partition and no leftover space, and when I discovered that WinMFS would do the expand without any leftover space I just happened to have used 999 on the swap partition size option, and when it worked I thought maybe that was why. Looking back, it might be that any number in the neighborhood of 1000 would work, that the trick is in using WinMFS to expand and not MFS Live, but having found a combination that works I'm sticking with it.

If someone wants to donate some hardware I'll experiment some more while I'm actually using my TiVo HD as a TiVo.

[Soapm]

Talk about some bad luck, the TivoHD has been running great the last few months when I decided, the tivo hasn't rebooted in a long time. I wonder how long it's been up. So I fired up TWP and took a look at info and it said 69+ days. I thought life is good. Then it started rebooting about every 20 minutes just like it did before. Darn it...

[Soapm]

Anyone have any clue what this line 33 error is talking about? I noticed some f those in the logs just before the reboots and not I see it before a forced fscheck.

Filesystem assert: false && "mfsassert" at fsassert_main.C line 33 in int fsassert_main(int, char**)
Filesystem flagged as inconsistent!
assert: Tmk Assertion Failure: false && "mfsassert"
assert: int fsassert_main(int, char**), line 33 (fsassert_main.C)
Tmk Fatal Error: Thread mfsassert <559> strayed!
Paste the following into a shell to get a backtrace...

bt -t /tvbin/tivoapp <<END_OF_BT
  tcd 1
  hpk Gen06
  build b-11-0-mr @443357 2011.01.05-1632 release-mips []
  pack 11.0k-01-2
  read 0x00400000 /tvbin/tivoapp
  read 0x04000000 /lib/libc.so.6
  read 0x04200000 /lib/libm.so.6
  read 0x04400000 /lib/libpthread.so.0
  read 0x04600000 /lib/libutil.so.1
  read 0x04800000 /lib/libtvutil.so
  read 0x04a00000 /lib/libtmk.so
  read 0x04c00000 /lib/libtvstructures.so
  read 0x2aaa8000 /lib/ld.so.1
  read 0x2ab08000 /platform/lib/libmp3dec.so
  read 0x2ab58000 /platform/lib/libcdsassetsentinelasf.so
  read 0x2aba0000 /platform/lib/libmomcds.so
  read 0x2abe8000 /platform/lib/libmomasf.so
  read 0x2ac38000 /platform/lib/libhpkhl.so
  read 0x2ad18000 /lib/libhpkoss.so
  read 0x2ad68000 /platform/lib/libhpkll.so
  read 0x2adb0000 /lib/librt.so.1
  read 0x2ae08000 /lib/libdl.so.2
  0x04a898dc 0x012577e4 0x0124cebc 0x0079acc8 0x007e47f0 0x0401455c
END_OF_BT

Tmk Fatal Error: Thread mfsassert <559>: assertion failure

[unitron]

There's been some mention over at TCF of S3 HD rebooting problems lately and I don't think it's all from people who used jmfs to put in a 2TB drive.

Of course if it's an S2 or S3 the power supply is always suspect whenever you get strange symptoms, but at least one guy on TCF has a pair of HDs that both started giving trouble at the same time.

[Soapm]

I think I figured mine out, my drive was filling up so I also deleted a lot of saved war movies and while I was in TWP I set a bunch of them like the King and I so that they won't record again. I think that's what caused the reboots. I think the no-re-record was causing the reboots.

I remembered I had set those files so I went back in there and set them all to remove and hit the update button. I've been up for 12 hours and 35 minutes since deleting everything in the list. I hope it holds out...