Tivo SA 2.5 + 7.1b kernel + 320Gig + mfsadd issues...

[cwerdna]

Originally Posted by Jamie

You can always run mkswap yourself. Have you seen this thread?

I've seen the thread but it was started in 2002 WAY before this new kernel ever shipped on Tivos. So are you saying I should do an mfsrestore with -s 200 (for example) and then do a /sbin/mkswap -v0 /dev/hdc8 [changing hdc8 to whatever is appropriate]?

http://www.courtesan.com/tivo/bigdisk.html seems to say that I need to use a v1 swap and do this:
# mkswap -v1 /dev/hda
# swapon -a

I'd rather do something that's tried and true rather than guessing and facing problems down the road if I hit a GSOD or weird behavior. Restoring from a backup is no fun since I'll lose my recordings.

[Jamie]

Originally Posted by cwerdna

I've seen the thread but it was started in 2002 WAY before this new kernel ever shipped on Tivos. So are you saying I should do an mfsrestore with -s 200 (for example) and then do a /sbin/mkswap -v0 /dev/hdc8 [changing hdc8 to whatever is appropriate]?

http://www.courtesan.com/tivo/bigdisk.html seems to say that I need to use a v1 swap and do this:
# mkswap -v1 /dev/hda
# swapon -a

I'd rather do something that's tried and true rather than guessing and facing problems down the road if I hit a GSOD or weird behavior. Restoring from a backup is no fun since I'll lose my recordings.

It has to be a v1 swap. works for me. But you *don't* want to run mkswap on /dev/hda. That's definitely wrong.

You can also just wait for the GSOD, and deal with the problem then. Just turn the alternate root partition into a second swap partition to double your swap space when you need it for the GSOD.

[cwerdna]

Originally Posted by Jamie

It has to be a v1 swap. works for me. But you *don't* want to run mkswap on /dev/hda. That's definitely wrong.

You can also just wait for the GSOD, and deal with the problem then. Just turn the alternate root partition into a second swap partition to double your swap space when you need it for the GSOD.

So, in place of /dev/hda, I should be putting in /dev/hdX where X corresponds to what will become the Tivo A drive, correct?

I'd much rather not deal w/the latter since it's a PITA. Given the choices of auto self-recovery vs. me having to screw around with it, I always take the former.

It sounds like I can verify that Tivo's properly using the swap by viewing the /proc/meminfo file. Can I view this file while the drives are hooked to my PC? I guess the alternative would be to look at Tivo's kernel (or maybe tvlog) log files, right? How about mfsassert to force a GSOD and see if it "recovers"? Can I easily do that on my DVR80?

[Jamie]

Originally Posted by cwerdna

So, in place of /dev/hda, I should be putting in /dev/hdX where X corresponds to what will become the Tivo A drive, correct?

If you run mkswap on /dev/hdX you'll be turning your whole disk into one big swap area. You just want to do the swap partition, /dev/hdX8.

I'd much rather not deal w/the latter since it's a PITA. Given the choices of auto self-recovery vs. me having to screw around with it, I always take the former.

understood.

It sounds like I can verify that Tivo's properly using the swap by viewing the /proc/meminfo file. Can I view this file while the drives are hooked to my PC? I guess the alternative would be to look at Tivo's kernel (or maybe tvlog) log files, right? How about mfsassert to force a GSOD and see if it "recovers"? Can I easily do that on my DVR80?

You'll have to check it once it's running on the tivo. TivoWebPlus displays it on the info package, for example. Or from a telnet or serial shell, run "swapon -s", examine /proc/swaps or /proc/meminfo. It should also be in the kernel log file. You should be able to pull the drive and mount the var partition to see the logs, if you don't want to hack the tivo to get shell access.

[cwerdna]

Ok, sorry to keep revisiting this. I was about to embark on the upgrade tonight when I realized I have another problem. I was going to let the full 80 gig to 300 gig complete drive copy go overnight while I was asleep. <sigh>

Where can I find a binary or better yet a bootable CD that has Todd Miller's updated mkswap for x86 that he references at http://www.courtesan.com/tivo/bigdisk.html? I have no means of easily recompiling mkswap.

The CD produced by burning ptvlba48-4.01.iso (which I think I got from http://www.ptvupgrade.com/products/s...1_license.html) seems to have the wrong version of mkswap.

(can't delete my own post, otherwise I would)
Nevermind, it seems the ISO at http://www.dealdatabase.com/forum/sh...ghlight=mkswap will do the job.

[Jamie]

Originally Posted by cwerdna

Where can I find a binary or better yet a bootable CD that has Todd Miller's updated mkswap for x86 that he references at http://www.courtesan.com/tivo/bigdisk.html? I have no means of easily recompiling mkswap.

That page is Series1 oriented. His mkswap patch just adds an option for byte swapping. You don't need that for a Series2. {Edit: read on: it looks like I was wrong about this...}

The CD produced by burning ptvlba48-4.01.iso (which I think I got from http://www.ptvupgrade.com/products/s...1_license.html) seems to have the wrong version of mkswap.

Last time I checked, PTVupgrade was using a really old kernel (2.4.4) and probably a really old mkswap. It could be that their mkswap pre-dates the addition of version 1 swap.

(can't delete my own post, otherwise I would)
Nevermind, it seems the ISO at http://www.dealdatabase.com/forum/sh...ghlight=mkswap will do the job.

That should work.

[cwerdna]

Damn, after making the 300 meg swap partition and doing mkswap -v1 /dev/hda8 (on the correct drive), it looks like the kernel doesn't work w/the swapfile. In my messages log, I see SwapTotal of 0kB where it used to be 64 megs.

Also in my kernel log, I can see it used to be able to add the 64 meg swap fine, I now see:
Activating swap partitions
Unable to handle swap header version 16777216
swapon: /dev/hda8/ Invalid argument

Oh well. It looks like I'm going to have to recopy my A drive over and just stick w/127 meg swap.

[Jamie]

Originally Posted by cwerdna

Damn, after making the 300 meg swap partition and doing mkswap -v1 /dev/hda8 (on the correct drive), it looks like the kernel doesn't work w/the swapfile. In my messages log, I see SwapTotal of 0kB where it used to be 64 megs.

Also in my kernel log, I can see it used to be able to add the 64 meg swap fine, I now see:
Activating swap partitions
Unable to handle swap header version 16777216
swapon: /dev/hda8/ Invalid argument

Oh well. It looks like I'm going to have to recopy my A drive over and just stick w/127 meg swap.

Odd. 2.4.20 kernels, such as the one in 7.1b, can definitely handle v1 swap. I run with a 256MB v1 swap. I created mine by running /bin/mkswap on the tivo itself.

Not sure what's going on here, but it seems like your swap area may not have been correctly initialized. Here's the code from the kernel that prints that message:

 
if (swap_header->info.version != 1) {
    printk(KERN_WARNING
           "Unable to handle swap header version %d\n",
           swap_header->info.version);
    error = -EINVAL;
    goto bad_swap;
}

Note that your swap_header->info.version is 16777216 = 0x1000000.
Looks like a byte order problem to me.

[cwerdna]

Originally Posted by Jamie

Odd. 2.4.20 kernels, such as the one in 7.1b, can definitely handle v1 swap. Not sure what's going on here, but it seems like your swap area may not have been correctly initialized.

Yeah. Maybe I did need a patched mkswap and the one on the Knoppix Lite CD was no good? It did support the -v1 flag from the "help" that it had and didn't complain about -v1 either.

[Jamie]

Originally Posted by cwerdna

Yeah. Maybe I did need a patched mkswap and the one on the Knoppix Lite CD was no good? It did support the -v1 flag from the "help" that it had and didn't complain about -v1 either.

I did a mkswap on a tivo box and and one on a x86 box and dumped the result:
tivo:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  00 00 00 01 00 00 ff ff  00 00 00 00 00 00 00 00  |................|
00000410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000ff0  00 00 00 00 00 00 53 57  41 50 53 50 41 43 45 32  |......SWAPSPACE2|
00001000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

x86:

00000000  07 3b 07 ba 53 54 46 90  88 62 ed cb 7d 3b 49 45  |.;..STF..b..};IE|
00000010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  01 00 00 00 ff 00 00 00  00 00 00 00 00 00 00 00  |................|
00000410  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000ff0  00 00 00 00 00 00 53 57  41 50 53 50 41 43 45 32  |......SWAPSPACE2|
00001000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Note the byte order of the integer start at offset 0x400.

The easy solution to this is to run mkswap on the tivo itself. Alternatively, get a mkswap that can do byte swaping of the integer fields. The patch at courtesan.com added a "-S" option to byte swap the integer fields. Perhaps the version on the knoppix cd has that option and you just need to use it?

[cwerdna]

Originally Posted by Jamie

IThe easy solution to this is to run mkswap on the tivo itself. Alternatively, get a mkswap that can do byte swaping of the integer fields. The patch at courtesan.com added a "-S" option to byte swap the integer fields. Perhaps the version on the knoppix cd has that option and you just need to use it?

Getting mkswap to run on the tivo itself might be tough for me. The knoppix CD's mkswap only supports -c -v0 -v1 -pPageSZ /dev/name [blocks].

I think I'm going to just put my 80 gig A drive back in for the time being. I've got plenty of space for now since TV shows are in hiatus. Unless I find an easily solution, I might just go grab a 160 gig drive to add and save the 300 for my next PC. :/

[Jamie]

Originally Posted by cwerdna

Getting mkswap to run on the tivo itself might be tough for me. The knoppix CD's mkswap only supports -c -v0 -v1 -pPageSZ /dev/name [blocks].

I think I'm going to just put my 80 gig A drive back in for the time being. I've got plenty of space for now since TV shows are in hiatus. Unless I find an easily solution, I might just go grab a 160 gig drive to add and save the 300 for my next PC. :/

Check your PM. I sent you a swap partition you can use.

[Jamie]

Here's a static linux x86 mkswap that includes the -S option to swap bytes in the integer header values.

[cwerdna]

Thanks for the help. I'll think about it when I have more time. Due to the errr... twists and turns this has taken, I'm a little concerned that there aren't that many people running w/>127 meg swap in conjunction w/really large drives on any Tivos. So it's unclear to me if some other unknown prob might come up and whether they can really recover properly from GSOD given this larger swap.

Divorcing my drives and losing my recordings cuz of some prob down the road is no fun.

Sorry to make this even more off topic. How much physical RAM does the RCA DVR80 have usable? I swear I saw a weird amount like ~43nnn KB in the kernel logs. I'd expected say 49152 or 40960K. I'm contemplating just adding the a 200 gig drive (they're cheap too) if the unit can recover from GSOD of ~280 gigs w/127 megs of swap.

[TiVo_jimbo]

Originally Posted by mike_s

Anyone who uses "giga-" (or "mega-," etc.) to refer to powers of 2 is, quite simply, incorrect. This despite that their use may be understood and commonly accepted within their area. These are internationally standardized SI prefixes, with specific, well defined meaning, and its powers of 10, NOT 2.

If you want to refer to powers of 2, the IEC has standardized appropriate prefixes, ex. "gibibyte." The US National Institute for Standards and Technology on prefixes.

Wrong. This is straight from your URL:

Faced with this reality, the IEEE Standards Board decided that IEEE standards will use the conventional, internationally adopted, definitions of the SI prefixes. Mega will mean 1 000 000, except that the base-two definition may be used (if such usage is explicitly pointed out on a case-by-case basis) until such time that prefixes for binary multiples are adopted by an appropriate standards body.

I'm so tired of this crap. Since most people are DUMB and don't want to learn something new, the smarter people must be wrong. WRONG! Computers don't talk in tens, they talk in twos. Period.

Before 48 bit addressing we had a 128 GB limit.
MFS Tools has a 256 GB problem.

And now, just for your amusement:

2^10 = 1,024 = 1 kilobyte = 1 KB
2^20 = 1,048,576 = 1 megabyte = 1 MB
2^30 = 1,073,741,824 = 1 gigabyte = 1 GB
2^40 = 1,099,511,627,776 = 1 terabyte = 1 TB