DSR704 and 6.2 reboots

[req]

I'm having a problem..and for the life of me, I haven't come to a conclusion..is my actual Tivo hardware bad?

I have another unit, a HDVR2 with 6.2 + MRV working perfectly..stable too

For this DSR704, here are the steps ive used.

mfsrestore -zxpi 62small.mfs
(reboot)
mount hdc4, run the NoCSO echo to tivoapp, replace iptables with exit script, dd a 3.1.5 (2.4.20) image to hdc3, killhdinitrd hdc3, add upgradesoftware=false to the bootpage, called rc.sysinit.author at the bottom of rc.sysinit, created rc.sysinit.author with bash, mount rw,remount /, and tivoftpd

popped it in the tivo, went thru setup. looks good.

when i record anything, about 18 minutes into it, tverr shows this:

Jun 23 04:49:29 (none) TvVideoLoopsetProxy::LeadIn[275]: PlayLoopset failed with 0x21004
Jun 23 04:50:11 (none) last message repeated 8 times
Jun 23 04:55:00 (none) last message repeated 5 times
Jun 23 04:56:22 (none) TvVideoLoopsetProxy::LeadIn[275]: PlayLoopset failed with 0x21004
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:0 BUF:0x5e94e440 COUNT:4
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:1 BUF:0x5e94f7ec COUNT:1056
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:2 BUF:0x2b087244 COUNT:1996
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:3 BUF:0x2b087a10 COUNT:6576
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:4 BUF:0x2b1955c0 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:5 BUF:0x2b195810 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:6 BUF:0x2b195a60 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:7 BUF:0x2b195cb0 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:8 BUF:0x2b0893c0 COUNT:7360
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:9 BUF:0x2b08b080 COUNT:10112
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:10 BUF:0x2b08d800 COUNT:6352
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:11 BUF:0x2b08f0d0 COUNT:5968
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:12 BUF:0x2b090820 COUNT:8896
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:13 BUF:0x2b195f00 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:14 BUF:0x2b196150 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:15 BUF:0x2b1963a0 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:16 BUF:0x2b1965f0 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:17 BUF:0x2b196840 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:18 BUF:0x2b092ae0 COUNT:6208
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:19 BUF:0x2b094320 COUNT:6352
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:20 BUF:0x2b095bf0 COUNT:7600
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:21 BUF:0x2b196a90 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:22 BUF:0x2b196ce0 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:23 BUF:0x2b196f30 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:24 BUF:0x2b197180 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:25 BUF:0x2b1973d0 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:26 BUF:0x2b0979a0 COUNT:5696
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:27 BUF:0x2b098fe0 COUNT:5216
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:28 BUF:0x2b09a440 COUNT:10176
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:29 BUF:0x2b197620 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:30 BUF:0x2b197870 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:31 BUF:0x2b197ac0 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:32 BUF:0x2b197d10 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:33 BUF:0x2b09cc00 COUNT:6624
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:34 BUF:0x2b09e5e0 COUNT:6304
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:35 BUF:0x2b197f60 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:36 BUF:0x2b1981b0 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:37 BUF:0x2b198400 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:38 BUF:0x2b198650 COUNT:592
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:39 BUF:0x2b09fe80 COUNT:9680
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:40 BUF:0x2b0a2450 COUNT:5856
Jun 23 06:12:00 (none) TmkTransform::Trace[246]: SEGMENT:41 BUF:0x5e94d4fc COUNT:16
Jun 23 06:12:00 (none) TmkAssertionFailure[246]: (putbuf, line 1506 ())
Jun 23 06:12:00 (none) TmkClipCache0[246]: Tmk Fatal Error: Thread TmkClipCache0 <246> strayed!
Jun 23 06:12:00 (none) TmkClipCache0[246]: bt -t /tvbin/tivoapp
Jun 23 06:12:00 (none) TmkClipCache0[246]: read 0x2aaa8000 /lib/ld.so.1
Jun 23 06:12:00 (none) TmkClipCache0[246]: read 0x2ab04000 /lib/libutil.so.1
Jun 23 06:12:00 (none) TmkClipCache0[246]: read 0x2ab48000 /lib/libdl.so.2
Jun 23 06:12:00 (none) TmkClipCache0[246]: read 0x2ab8c000 /lib/libpthread.so.0
Jun 23 06:12:00 (none) TmkClipCache0[246]: read 0x2abe8000 /lib/libm.so.6
Jun 23 06:12:00 (none) TmkClipCache0[246]: read 0x2acb0000 /lib/libc.so.6
Jun 23 06:12:00 (none) TmkClipCache0[246]: 0x00dca7b0 0x00dd07bc 0x00dd0590 0x00dccad0 0x00dd1f78 0x00e02100 0x00e013ac
Jun 23 06:12:00 (none) TmkClipCache0[246]: 0x013a706c 0x013ce190
Jun 23 06:12:00 (none) TmkClipCache0[246]: Tmk Fatal Error: Thread TmkClipCache0 <246>: assertion failure
Jun 23 06:12:00 (none) TmkClipCache0[246]: Tmk Fatal Error: Thread died due to signal -2
Jun 23 06:12:00 (none) TmkClipCache0[246]: Invoking rule 834: rebooting system

Thought it may have been the drive...nope, it passes low level checks..even tried a new drive. same results. tried it with and without the MRV patches. only thing i havent tried was using a stock tivoapp (without the nocso patch).. though i dont see how it can be this.

im at a loss here...im not too familiar with what Tmk is.. anyone have any input how i can diagnose this further?

[req]

Something else I wanted to point out...

my HDVR2 system:
151 service number running 6.2-01-2-321 (shows up as DSR7000 in info)
obviously identical units

my DSR704 system:
301 service number also running 6.2-01-2-321 (show up as DSR7000 in info)

question here..is this the problem? Were the different slices custom to their destination units (RID versus non-RID?)

[PlainBill]

The hardware description is nothing but a string in the mfs database; alldeadhomiez wrote a script (http://www.dealdatabase.com/forum/showthread.php?t=39866) to change it.

Apply the standard troubleshooting procedure: Take one of the drives that are failing on the DSR704, run AlphaWolf's 51killer.tcl (it's in his Series 2 binaries) and put it in the HDVR2. See if the problem shows up there too. Doing the reverse - putting the drive from the HDVR2 into the DSR704 is a little riskier.

PlainBill

[req]

So the different slices really contain identical software..?

I'll try popping the HDVR2 drives in the DSR704 and I guess that will answer my question!

[req]

Last night I tried putting the DSR704 drives into the HDVR2..same result. Leads you to believe its my image.. though I installed the HDVR2 from the same image. I ended up mfsretoring alldeadhomiez mfs image to the DSR704, *only* put 3.1.5 on /dev/hdx3 and killhdinitrd'd it..and popped it back into the tivo. I ended up running fakecall.tcl (with the correct mod) to get recording ability. The problem *still* exists. I'm wondering if the only reason the problem still occurred on the HDVR2 is because something already corrupted itself on the DSR704 drives....

agghhhhhh