Green screen / reboot, after hd upgrade

[Roadblock]

I'm trying to upgrade a TCD540040 Tivo (40 GB) to a 120 GB hd. I used the Hinsdale (http://www.newreleasesvideo.com/hinsdale-how-to/index9.html) guide and the free LBA48 boot CD from ptvupgrade (http://www.ptvupgrade.com/products/software/lba48/index.html).

When I booted up from the CD, it recognized both hard drives with the correct sizes (40 and 120).

I went with Upgrade Configuration #3 to preserve the recordings and ran this command:

mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -xzpi - /dev/hda

I let it run overnight and in the morning it appeared to have worked ok, giving me a message saying success and the new size of the drive, so I put the new drive in the Tivo. On bootup, though, I got the green screen, which I let run, followed by endless reboots. I put the old drive back in and it works fine for now. Anyone know what I did wrong here?

I searched the forum and found some others with similar issues, but no posted solutions. Thanks in advance for any help.

[funtoupgrade]

Make sure your drive jumper is in the correct position and that ribbon cable is not accidently reversed. Easy for anybody, experienced or not to do when not careful.

[Roadblock]

Make sure your drive jumper is in the correct position and that ribbon cable is not accidently reversed. Easy for anybody, experienced or not to do when not careful.

Doesn't seem to be the problem. The jumper is set to master and the cable looks correct, but I still get the same issue.

[HomeUser]

JFWIW Try setting the jumper to CS or Master without Slave if you have that option. What is the brand and model of your new HD?

Other then cable/jumper settings look at the TiVo's log files put the drive back in the PC boot mfstools cd, "mkdir /mnt/tivo", "mount /dev/hda9 /mnt/tivo", "cat mnt/tivo/var/log/kernel.log".

[Roadblock]

Took me awhile to get back to work on this, but the old hard drive is a Maxtor QuickView DiamondMax Plus 8 ATA/133 HDD, 40GB. The new one is a Seagate Barracuda 7200.7 120 GB, Model ST3120026A.

Other then cable/jumper settings look at the TiVo's log files put the drive back in the PC boot mfstools cd, "mkdir /mnt/tivo", "mount /dev/hda9 /mnt/tivo", "cat mnt/tivo/var/log/kernel.log".

I put the drive back in booted up from the lba48 upgrade CD. /mnt/tivo already exists, but there's no /mnt/tivo/var. After mounting hda9 I did find a log in /mnt/tivo/log/kernel.

I didn't boot with my Windows drive attached, so I don't how else to transfer the log here, but here are some lines with timestamps removed of possible interest:

>kernel: Logger not initialized! Logging to stdout:

>kernel: Failed to load document named "/atlas_uicommon/ui/Hello/TvAtlasHello.brf"
>kernel: Error 0x30001 (0x30001)

>kernel: Illegal read at 00000078
>kernel: do_page_fault #2: sending signal 11 to SiHost(264)

followed by what looks like register dumps ($0, $8, $16, $24, Hi, Lo, epc, Status, Cause)

>kernel: Tmk Fatal Error: Activity SiHostActivity <264> strayed!
...
>kernel: Tmk Fatal Error: Activity SiHostActivity <264>: unexpected signal 11

It looks like it then does some initialization and scanning of all the directories followed by the message:

>kernel: The filesystem seems to be OK

After more loading of drivers it says,

>kernel: ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda9 is mounted.^M
>kernel: /dev/hda9 was not cleanly unmounted, check forced.
>kernel: Inode 8220, i_blocks_wrong 136 (counted=132). Set i_blocks to counted? yes
>kernel:
>kernel: Inode 8217, i_blocks_wrong 4884 (counted=4876). Set i_blocks to counted? yes
>kernel:
>kernel: Inode 8218, i_blocks_wrong 704 (counted=702). Set i_blocks to counted? yes
>kernel:
>kernel: Fix summary information? yes
>kernel:
>kernel: /dev/hda9: 76/32768 files (11.8% non-contiguous), 7648/131072 blocks
>kernel: Cleanup /dev/hda9 pass 2
>kernel: ext2fs_check_if_mount: No such file or directory while determining whether /dev/hda9 is mounted.^M
>kernel: /dev/hda9: clean, 76/32768 files, 7648/131072 blocks
>kernel: /dev/hda9 is clean after pass 2

The log repeats the above information several times with slightly different information about the inodes and number of blocks when it restarted before I turned off the tivo.

Is this information helpful? Because I don't understand it, other than to say it looks like there are bad blocks on the drive, or were bad blocks on the old drive that were copied over. But the old drive is working ok (for now) and the new drive is not.

[HomeUser]

The log file should fit on a floppy (if your PC has one)

Yep :o /mnt/tivo/log/ is where the files should be when mounted on the PC.

It does look like it there was a bad copy you might re-try using a new fine ribbed ribbon cable especially if your PC has a high speed EIDE controller

Run the manufactures diagnostics on the drive run the long version before re-doing the backup/restore again.

You might make the backup/restore a two step process copy keeping the recordings without expanding with mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -zpi - /dev/hda check the drives operation in TiVo then put it back in the PC and expand the drive with mfsadd -x /dev/hda

The jumper farthest away from the power connector is the one that should be installed for running in the Tivo. ST3120026A Illustrated Configuration (http://www.seagate.com/support/disc/ata/st3120026a.html)

[Roadblock]

I ran the Maxtor and Seagate diagnostic tools on the drives. The Seagate is OK, but the Maxtor tool said the drive is failing and gave a diagnostic error d2699179. Should I still be able to copy from this drive? Or is that the cause of my problems?

[litzdog911]

I ran the Maxtor and Seagate diagnostic tools on the drives. The Seagate is OK, but the Maxtor tool said the drive is failing and gave a diagnostic error d2699179. Should I still be able to copy from this drive? Or is that the cause of my problems?

Hard to say without knowing what that Maxtor error code means, but I think it's safe to conclude that the drive is toast.

[Roadblock]

Hard to say without knowing what that Maxtor error code means, but I think it's safe to conclude that the drive is toast.

If I put it in the tivo it seems to work ok, but after awhile it gets some pauses and playback problems. I'm already trying to move it to a new drive, just curious if anyone has had success with mfsbackup from a failing drive to a new one.

[HomeUser]

Instead of mfsbackup | restore I would make a binary copy of the failing drive ASAP see the Linux commands cp, dd or dd_rescue. If the data is really important sometimes SpinRite can recover all or some of the data in the failing area of the drive long enough to copy.

If you can set the drive where it can get a lot of air flow. Keep the drive cool seems your errors get worse with time.

[Roadblock]

You might make the backup/restore a two step process copy keeping the recordings without expanding with mfsbackup -Tao - /dev/hdc | mfsrestore -s 127 -zpi - /dev/hda check the drives operation in TiVo then put it back in the PC and expand the drive with mfsadd -x /dev/hda


Tried this, but the backup doesn't work anymore. I got the error message: "Restore failed, internal error 3 (0.69%)"

[HomeUser]

I going to guess that the error was caused by a read error. Did you have a fan blowing air on the drive?

The options I see at this point is copy the drive with errors using dd_rescue or Try recovering the bad blocks with SpinRite then copy the drive.

[Roadblock]

Edit: Deleted until I try a few more things I found in this forum...

[Roadblock]

Success! At least for now. I looked into dd_rescue and went with the advice from this (http://www.tivocommunity.com/tivo-vb/showthread.php?t=298508) thread which fortuitously appeared around the same time. I used the dd_rescue on the knoppix cd. The one on the ptvupgrade cd gave me a segmentation fault and it has different options (older version I guess?).

The process was pretty quick. It cruised through 22GB of the dd_rescue at about 19MB/sec. Then it clicked and ground to a halt while it went through 500K of errors for about 15 minutes. After it got through that, though, it sped up again to 19MB/sec and finished the copy. I expanded the partition to 120GB with mfsadd from the mfstools and it seems to be working fine. Tivo booted up with no errors and the recordings look ok. I don't know what was in that 500K. Maybe one of the recorded shows has a second of black screen now or something?

It's working for now, and hopefully it will last. Thanks for all your help HomeUser, I appreciate it!

[Roadblock]

Bah, wishful thinking I guess. After a couple hours it froze and restarted. Then it went to the GSOD, followed by endless reboots. So I'm back where I started...

[HomeUser]

1st Check your connections (and the fan) then have another look at the log files.

DD_Rescue probably slowed down reading the bad blocks. The GSOD could be from too little swap space I don't recall what the default that that comes with the 40G drive a 120G should have at least 60M of swap.

[Roadblock]

1st Check your connections (and the fan) then have another look at the log files.

DD_Rescue probably slowed down reading the bad blocks. The GSOD could be from too little swap space I don't recall what the default that that comes with the 40G drive a 120G should have at least 60M of swap.

From the output of pdisk -l, partition 8 (linux swap) is 128.0M on both drives. I know the backup procedure usually sets -s 127. Is this a problem?

[Roadblock]

And if it helps, this is the first portion of the log...

May 7 02:20:03 (none) kernel: Logger not initialized! Logging to stdout:
May 7 02:20:03 (none) kernel: TmkLogger: <133>May 7 02:20:03 TmkServer[245]: Enabling port 5353, protocol udp
May 7 02:20:07 (none) kernel: Failed to load document named "/silicon/lib/silicon/SiDefaults.brf"
May 7 02:20:07 (none) kernel: Error 0x30001 (0x30001)
May 7 02:20:07 (none) kernel: TvUrlResource BaseUrl is "shmem://TvShmemd"
May 7 02:20:07 (none) kernel:
May 7 02:20:07 (none) kernel: Check to be sure:
May 7 02:20:07 (none) kernel: If you're using TV_URL_RESOURCE_BASE that it points to a
May 7 02:20:07 (none) kernel: valid directory
May 7 02:20:07 (none) kernel: If you're on a load-all system that your document's ism is listed
May 7 02:20:07 (none) kernel: in sw/data/common/gen/import-processes/import-processes.list
May 7 02:20:07 (none) kernel: If you've added/changed this Document in your tree check that
May 7 02:20:07 (none) kernel: your content is in your $TIVO_ROOT (ie, make linkimage)
May 7 02:20:07 (none) kernel:
May 7 02:20:07 (none) kernel: Illegal read at 0000006c
May 7 02:20:07 (none) kernel: do_page_fault #2: sending signal 11 to SiHost(262)
May 7 02:20:07 (none) kernel: $0 : 00000000 01890590 00000000 00000002 00000000 00000000 5ec54220 5ec54288
May 7 02:20:07 (none) kernel: $8 : 00000001 ffffffff 00000000 00000003 8017641c 80599480 80142cf4 80599400
May 7 02:20:07 (none) kernel: $16: 00000000 00000000 00000012 100f7760 7fff77c5 5ecebc90 7fbff738 101123d8
May 7 02:20:07 (none) kernel: $24: 00000000 02a2a8e4 0218a5a0 7fff6348 7fbff7f0 0074c85c
May 7 02:20:07 (none) kernel: Hi : ffffd9fc
May 7 02:20:07 (none) kernel: Lo : 00000cac
May 7 02:20:07 (none) kernel: epc : 0074c878 Tainted: P
May 7 02:20:07 (none) kernel: Status: 80008413
May 7 02:20:07 (none) kernel: Cause : 00800008
May 7 02:20:07 (none) kernel: 800b5870 800b588c 800b9ca4 800b9ff8 800bbf04
May 7 02:20:07 (none) kernel: 0074c878 02a4ab1c 02a4cee4 02a5ac58 02a59c08 0064f4b8 0076b230 006fe154
May 7 02:20:07 (none) kernel: 0201455c
May 7 02:20:07 (none) kernel: Tmk Fatal Error: Thread SiHost <262> strayed!
May 7 02:20:07 (none) kernel: pc 0x74c878 status 0x80008413 cause 0x800008 bva 00000000 hi 0xffffd9fc lo 0x000cac
May 7 02:20:07 (none) kernel: R00 0x00000000 R01 0x01890590 R02 0x00000000 R03 0x00000002
May 7 02:20:07 (none) kernel: R04 0x00000000 R05 0x00000000 R06 0x5ec54220 R07 0x5ec54288
May 7 02:20:07 (none) kernel: R08 0x00000001 R09 0xffffffff R10 0x00000000 R11 0x00000003
May 7 02:20:07 (none) kernel: R12 0x8017641c R13 0x80599480 R14 0x80142cf4 R15 0x80599400
May 7 02:20:07 (none) kernel: R16 0x00000000 R17 0x00000000 R18 0x00000012 R19 0x100f7760
May 7 02:20:07 (none) kernel: R20 0x7fff77c5 R21 0x5ecebc90 R22 0x7fbff738 R23 0x101123d8
May 7 02:20:07 (none) kernel: R24 0x00000000 R25 0x02a2a8e4 R26 0x00000000 R27 0x00000000
May 7 02:20:07 (none) kernel: R28 0x0218a5a0 R29 0x7fff6348 R30 0x7fbff7f0 R31 0x0074c85c
May 7 02:20:07 (none) kernel: Paste the following into a shell to get a backtrace...
May 7 02:20:07 (none) kernel:
May 7 02:20:07 (none) kernel: bt -t /tvbin/tivoapp <<END_OF_BT
May 7 02:20:07 (none) kernel: tcd 1
May 7 02:20:07 (none) kernel: hpk Gen04
May 7 02:20:07 (none) kernel: build b-7-2-2-mr @226264 2006.02.21-2147 release-mips [SET_7_2_2_OTHER]
May 7 02:20:07 (none) kernel: pack 7.2.2-oth.01-2
May 7 02:20:07 (none) kernel: read 0x00400000 /tvbin/tivoapp
May 7 02:20:07 (none) kernel: read 0x02000000 /lib/libc.so.6
May 7 02:20:07 (none) kernel: read 0x02200000 /lib/libm.so.6
May 7 02:20:07 (none) kernel: read 0x02400000 /lib/libpthread.so.0
May 7 02:20:07 (none) kernel: read 0x02600000 /lib/libutil.so.1
May 7 02:20:07 (none) kernel: read 0x02800000 /lib/libtvutil.so
May 7 02:20:07 (none) kernel: read 0x02a00000 /lib/libtmk.so
May 7 02:20:07 (none) kernel: read 0x02c00000 /lib/libtvstructures.so
May 7 02:20:07 (none) kernel: read 0x2aaa8000 /lib/ld.so.1
May 7 02:20:07 (none) kernel: read 0x2ab04000 /lib/libhpkoss.so
May 7 02:20:07 (none) kernel: read 0x2ab50000 /platform/lib/libhpkhl.so
May 7 02:20:07 (none) kernel: read 0x2ac14000 /platform/lib/libhpkll.so
May 7 02:20:07 (none) kernel: read 0x2ac58000 /lib/libdl.so.2
May 7 02:20:07 (none) kernel: 0x0074c878 0x02a4ab1c 0x02a4cee4 0x02a5ac58 0x02a59c08 0x0064f4b8 0x0076b230
May 7 02:20:07 (none) kernel: 0x006fe154 0x0201455c
May 7 02:20:07 (none) kernel: END_OF_BT
May 7 02:20:07 (none) kernel:
May 7 02:20:07 (none) kernel: Tmk Fatal Error: Thread SiHost <262>: unexpected signal 11

[HomeUser]

I think -s 127 makes a 128M swap. Anyway if the kernel sees it as 128M that should be fine. You could re-make it with tpip just to be sure.


I don't know what SiHost is doing a google search it appears in a Linux driver for a serial line controller chip.

Just a thought, there is a backup image of the key software saved somewhere you could trigger the restore by invalidating the boot checks by making a change to one of the startup scripts like rc.sysinit on partition 4 or 7. Other then that restoring from a good image may be the easy solution.

[ovit4me]

I have a similar problem and I'm pretty certain it's not a HW issue for me. I used the PVTupgrade to add a 300G drive to my TiVo unit. The whole process went fine. The PVTupgrade CD can see my large drive with the correct size just fine. I looked at the log and the swap size is already 128MB. I will try to get the logs to the floppy and post it here. When I ran mfsadd -x, it reported the new size just fine (about 351 hours). I even used mfsinfo to look at the new MFS volume and it reported everything as hunky dory. I popped both drives in and it kept rebooting endlessly. I let it run for 2 hours to no avail. Popped the drives back into my PC and looked at the kernel log again and it gave me the same tmk error that I found on this thread.

Roadblock - Did you get your issue resolved?