PDA

View Full Version : Could Swap size cause reboots on 6.3f?


bpratt
03-13-2008, 01:36 PM
I have never had a single problem with either of my two HR10-250s since 6.3d was released. During the problems with 6.3, 6.3a and 6.3b, I restored both of my systems to 3.1.5f and unplugged the phone line. Once 6.3d was released, I plugged in the phone line and have been stable with no problems on 6.3d, 6.3e and now 6.3f.

I read in these forums a few years ago about reboots and other problems if the swap size was too small when you went to a larger disk in the HR10. So I doubled the size of the swap file using the following restore:
mfsrestore -s 256 -r 4 -zxpi /mnt/backuplbak /dev/hdc

I now wonder if 6.3x requires a larger swap size than did 3.1.5f and that may be the cause of many of the reboots. One of my HR10 was built in 2004, so it is the model with the old HDMI card. The other HR10 is newer and has the new HDMI card, so I have one of each of the two HR10 models.

Mostly I record OTA but I also record some of the MGEG2 stuff from D*.

TyroneShoes
03-13-2008, 02:56 PM
That's really interesting.

But still is anecdotal evidence that may be only a product of superstition. That does not mean I am unwilling to be convinced by real evidence, but one would think that if this were significant there would be lots of info out there about it. There isn't.

So let the speculation begin:

I'm certainly no expert, but do we even know that these simple OS's use virtual memory at all?

I thought that the swap file was sized to match the throughput requirements of the tasks expected to be done, and is hopefully fully-vetted during original design. It would be unexpected that Tivo would have gotten this wrong, and even more-unexpected that the requirement would change due to an up rev, or that Tivo would release an up rev that imperiled the stability of the platform due to a now-too-small swap file size. That should be programming 101.

Further, PVR read/write is a low-throughput task, and nothing about that changes when the storage size changes, other than a possible lessening of throughput requirements when a second drive is added.

So I am skeptical, but remain open-minded.

[edit]

From another post on the forum, it appears that you did the swap file upsize before you allowed even 6.3a/b, which you stated you had problems with similar to others' problems posted here. If so, and unless an up rev defaults the swap file size back to original size, I think you may have your answer as to whether that helps or not. Or did you do the upsize more recently?

bpratt
03-13-2008, 03:36 PM
From another post on the forum, it appears that you did the swap file upsize before you allowed even 6.3a/b, which you stated you had problems with similar to others' problems posted here. If so, and unless an up rev defaults the swap file size back to original size, I think you may have your answer as to whether that helps or not. Or did you do the upsize more recently?

I did the upsize of the swap file on version 3.1.5f. Since I don't have the box hacked, I can't see if it is still the larger size without removing the drive, putting in my PC and booting lynix. I doubt very much that an update changes file sizes unless they need to be expanded.

Here are some threads that talk about swap size:
http://www.tivocommunity.com/tivo-vb/showthread.php?t=362254
http://www.tivocommunity.com/tivo-vb/showthread.php?t=291124

My impression from reading through several forum items in the past is that swap is used heavily during error recovery. If not enough space, the system will crash with a hard error. Lynix systems usually reboot after a hard error.

Da Goon
03-13-2008, 03:37 PM
Swap size won't change unless you do it by hand.

TyroneShoes
03-13-2008, 03:47 PM
I did the upsize of the swap file on version 3.1.5f...I doubt very much that an update changes file sizes unless they need to be expanded.

Here are some threads that talk about swap size:
http://www.tivocommunity.com/tivo-vb/showthread.php?t=362254
http://www.tivocommunity.com/tivo-vb/showthread.php?t=291124

My impression from reading through several forum items in the past is that swap is used heavily during error recovery. If not enough space, the system will crash with a hard error. Lynix systems usually reboot after a hard error.
Thanks for amplifying on that, but if you did the upsize at 3.1 and then had issues beginning with 6.x which retained the larger size, that sort of goes to prove that an expanded swap file size has no value in this situation, does it not?

bpratt
03-13-2008, 04:03 PM
Thanks for amplifying on that, but if you did the upsize at 3.1 and then had issues beginning with 6.x which retained the larger size, that sort of goes to prove that an expanded swap file size has no value in this situation, does it not?
The only problems I had with 6.3a and 6.3b were audio dropouts mostly on FOX. I never had problems with the original 6.3 and I never ran on 6.3c.

TyroneShoes
03-13-2008, 08:00 PM
The only problems I had with 6.3a and 6.3b were audio dropouts mostly on FOX. I never had problems with the original 6.3 and I never ran on 6.3c.

OK, Senator. No one's under oath here, and I am not trying to bust your chops pr paint you into a corner for sport, just to try to see if the theory you postulated here has merit or not, simply because those of us who unplugged prior to 6.x (and even more importantly those of us who didn't) are wondering if there is a solution to the issues of 6.x. If there are good ideas, we all want to hear them.

Your theory sounded intriguing, but then you appeared to blow it back out of the water by saying you tried it and it didn't help. But I'm not quite sure if that is what you are saying or just what I am hearing.

It's not about you, it's about whether this could be a helpful process or not. So a simple, direct answer to the central question is probably the best thing you could do to either put this behind us or to help us and yourself at this point.

Again, if you upsized, later uprevved, and then began experiencing problems for the first time, which is what it sounds like, how is the question of upsizing still on the table as a credible theory? You appear to have disproven the theory simply by empirically testing it . If so, that's still progress. But without your answer we have very little at all.

bpratt
03-13-2008, 08:37 PM
If you had tried any of the 6.3 versions, you would know that everyone was having audio drop out problems on versions 6.3a and 6.3b. There was a bug that caused the audio to shut off for about 10 seconds mainly on, but not limited to FOX.

Because I did not want to live with the problem, I restored both of my HR10s back to 3.1.5f and watched the forums for a new fixed version. I believe the audio problem was fixed by version 6.3c, but I didn't re-connect my phone line until 6.3d was out and tested for a few weeks.

I only ran my first HR10 for about a month with the original 250 G drive. When I added a second 300 G drive, I increased the swap size. My second HR10 was never turned on with the original drive. When I received it, I replaced the 250 G drive with a 500 G drive and increased the swap size.

Other than audio problems on versions 6.3a and 6.3b, I have never had either HR10 reboot or lock up.

If the swap space is used by the TiVo or Lynix code for error recovery purposes, (There are several forum entries that indicate that it is) and if running out of swap space causes a reboot, then maybe the reason I have never had reboot problems is because I increased the swap space.

I have never had either HR10 on a UPS and I have had several power outages during the last several years, somtimes during a recording. I would expect that would possibly leave a bad spot on the disk. My theory is that my system with the extra swap space is able to recover these bad disk areas, and some of you who have constant reboots don't recover because you run out of swap space during the recovery process.

funinthesun
03-13-2008, 09:15 PM
lots of freezing and reboots are being posted - more and more each day. it could just be 6.3f imo for those boxes. again we used brand new drives on my friends units and it keeps happening.

Da Goon
03-13-2008, 09:35 PM
One thing left out is the method of upgrading. If you used older versions of mfstools instead of mfslive, then if you did not take extra steps to initialize the swap, you'd actually be running without any at all. Older versions of mfstools can't properly initialize a swap size larger than 127 megs without taking extra steps after the restore.

---just noticed in the OP you used "mfsrestore". Mfslive uses simply "restore". So if you didn't take any extra steps (tpip??), then your 256 meg swap was never properly initialized, and there was no point in trying to create a larger swapfile.

TyroneShoes
03-13-2008, 09:35 PM
If you had tried any of the 6.3 versions, you would know that everyone was having audio drop out problems on versions 6.3a and 6.3b. There was a bug that caused the audio to shut off for about 10 seconds mainly on, but not limited to FOX.

Because I did not want to live with the problem, I restored both of my HR10s back to 3.1.5f and watched the forums for a new fixed version. I believe the audio problem was fixed by version 6.3c, but I didn't re-connect my phone line until 6.3d was out and tested for a few weeks.

I only ran my first HR10 for about a month with the original 250 G drive. When I added a second 300 G drive, I increased the swap size. My second HR10 was never turned on with the original drive. When I received it, I replaced the 250 G drive with a 500 G drive and increased the swap size.

Other than audio problems on versions 6.3a and 6.3b, I have never had either HR10 reboot or lock up.

If the swap space is used by the TiVo or Lynix code for error recovery purposes, (There are several forum entries that indicate that it is) and if running out of swap space causes a reboot, then maybe the reason I have never had reboot problems is because I increased the swap space.

I have never had either HR10 on a UPS and I have had several power outages during the last several years, somtimes during a recording. I would expect that would possibly leave a bad spot on the disk. My theory is that my system with the extra swap space is able to recover these bad disk areas, and some of you who have constant reboots don't recover because you run out of swap space during the recovery process.

Thank you. Now we're getting somewhere (I think). You have not empirically disproven it, and the jury is still out.

But I still would suspect that Tivo would not allow a too-small swap size to endanger reliability, and would have vetted that during testing. But then I would also suspect that someone at the level of Governor would not endanger his family's well-being by paying for prostitutes, or that the executive branch of the U.S. government would not try to convince us that ridding the world of Sadaam Hussein was a reasonable response to 9/11, so I guess anything is possible.

Possibly 6.x needs a larger swap size and there is no way to include that in an up rev without the threat of it wiping out recordings. If that is the case, that means that they deliberately sabotaged reliability in the name of more auxiliary features, which I would have heartily recommended against, were my name Tom Rogers. Let's hope not.

Da Goon
03-13-2008, 09:39 PM
Could somebody with a stock image check the default swapfile size on an HR10? I believe on SD boxes it's only 64 megs. pdisk -l /dev/hdX will read out the partition table. (X being a-z depending upon where the drive is mounted in the pc's IDE chain).

TyroneShoes
03-13-2008, 09:41 PM
One thing left out is the method of upgrading. If you used older versions of mfstools instead of mfslive, then if you did not take extra steps to initialize the swap, you'd actually be running without any at all. Older versions of mfstools can't properly initialize a swap size larger than 127 megs without taking extra steps after the restore.

---just noticed in the OP you used "mfsrestore". Mfslive uses simply "restore". So if you didn't take any extra steps (tpip??), then your 256 meg swap was never properly initialized, and there was no point in trying to create a larger swapfile.

This is a good cautionary tale about a little knowledge being a dangerous thing. It is also why I leave all of the tinkering up to Weaknees or other 3rd-party drive providers, who likely have the level of expertise that Da Goon appears to possess.

TyroneShoes
03-13-2008, 09:49 PM
Could somebody with a stock image check the default swapfile size on an HR10? I believe on SD boxes it's only 64 megs. pdisk -l /dev/hdX will read out the partition table. (X being a-z depending upon where the drive is mounted in the pc's IDE chain).

Now we really ARE getting somewhere.

Let me throw one more thing out:

If I'm a major PVR provider in 2003 and I am about to vet a new HD product that I expect to add future features to by regular download, would not one of the things I would be sure to do be to make an educated guess about what the swap file requirements might be 5 years down the road and then quadruple that right at the outset?

I still say it seems unlikely that programmers this talented would not think to do this, since doing it only carries a penalty of a few MB while not doing it might hamper new features or torpedo reliability.

funinthesun
03-14-2008, 04:11 AM
dont you actually have a job somewhere?

you wanna tell me how the management there performs logical thinking on projects?

d* is no different. in fact they are worse at planning.

take this recent hr21 pile-o-garbage. tell me they couldnt work it out better then they did so as not to have thousands of posts of problem after problem instead of kudos.

did they think planned ahead now or then as a major PVR provider?

answer: no.

dont know about the swap problem but the point is that their own look ahead doesnt function either :D

bpratt
03-14-2008, 10:03 AM
One thing left out is the method of upgrading. If you used older versions of mfstools instead of mfslive, then if you did not take extra steps to initialize the swap, you'd actually be running without any at all. Older versions of mfstools can't properly initialize a swap size larger than 127 megs without taking extra steps after the restore.

---just noticed in the OP you used "mfsrestore". Mfslive uses simply "restore". So if you didn't take any extra steps (tpip??), then your 256 meg swap was never properly initialized, and there was no point in trying to create a larger swapfile.

I used the upgrade CD I downloaded from WeaKnees, and yes I do realize that on the older versions of the CD an extra step was needed to initialize the swap, and I took that step. During the 6.3a and 6.3b problems, I had downloaded the newer upgrade CD which does not require the extra step because it performs it automatically for you.

TyroneShoes
03-14-2008, 10:45 PM
dont you actually have a job somewhere?... Did someone forget to wipe?

Ignoring the obvious fact that it's absolutely none of your business, really, why the cheap shot? Maybe my powerball winnings will eventually run out some day and I'll have to get a job, yes, but I think that's beside the point and I'm not really sure I like your tone. It's as if you are saying I don't have a right to join this conversation while (example follows) you do. Congratulations on being elected Supreme Governor of the Internet.

...take this recent hr21 pile-o-garbage. tell me they couldnt work it out better then they did so as not to have thousands of posts of problem after problem instead of kudos.

did they think planned ahead now or then as a major PVR provider?

answer: no... Not only that (now that you've gone and opened that door), you state this as if it's the gospel, while we all know that you have no real idea what DTV had in mind or how they strategized their business plan, just like the rest of us don't. How arrogant. We are merely speculating while you seem to be proclaiming and proselytizing. It's not going to go over well, as that approach regularly seems to backfire.

It's always sad when cousins intermarry.

You are ignoring the big picture and whining about your one little anecdotal experience that didn't go exactly the way you wanted it to, which has very little to do with anything. It's just your singular little opinion, and not a well-held one with much credibility at that, so I predict that most folks would find that broken record nothing but boringly annoying and therefore a colossal waste of everyone's time.

I still like Tivo a lot better and I'm no fanboy for it or the HR2x, but successful companies like DTV don't put out defective hardware and then increase subscribers and increase profits immediately afterwards as a result, and the actual facts are that the DVR+ has been very successful for them, so most folks must be happy with it, your experience and a thousand whiner posts notwithstanding.