TiVo Community Forums Archives - getting wierd stutters.....

TiVoCommunity.com
(c)opyright 1995-2005 All rights reserved
indexcheckTC
This area is a static history of posts in the TiVo Community Forum Archive.
This archive history was made for the simple indexing of search sites like Google.

Pages:1

getting wierd stutters.....
(Click here to view the original thread with full colors/images)

Posted by: philhu

I know this has been covered, but just checking...

SVR-2000

40gig orig drive, added 120 gig drive.

Stuttering, freezing, reboots occasionally, looking in the kernel log, seeing:

Aug 30 19:43:12 (none) kernel: Stopping immediate on Ide
Aug 30 19:43:12 (none) kernel: IDE: tivo DMA engine aborted
Aug 30 19:43:12 (none) kernel: hda: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
Aug 30 19:43:12 (none) kernel: hda: irq timeout: error=0x00 { }, secCnt=140, LBAsect=43007668
Aug 30 19:43:12 (none) kernel: IDE: DMA in a strange state
Aug 30 19:43:12 (none) kernel: FPGA callback with DMA not running - delayed interrupt?
Aug 30 19:43:33 (none) kernel: tcp_keepalive: call keepopen(0x803c26c0)

I am assuming that my a drive is going.

Questions.....

If it is a 40gig, can I just dd it to a new 40 gig drive?
Is it better to use mfstools? If so, what kind of command would work?

Thanks

Posted by: Robert S

You can't use MFS Tools because that can only copy entire MFS sets.

dd is covered well in Hinsdale.

dd if=/dev/hdc of=/dev/hdb bs=32k conv=noerror,sync

Make sure that the drive you buy is at least as large as your Quantum. Quantum 40Gb drives are 40027Mb, Seagate (and most others, it seems) are 40021Mb. This is a problem. If you absolutely have to use a smaller drive, you can rebuild the partition table with pdisk, making the swap (8) and/or var (9) partitions slightly smaller. You then dd the partitions across individually.

If you resize swap you need to run mkswap -v0 /dev/hdc8 to reinitialise. There's no need to format var as the TiVo can do that itself and you only need to copy the active system partitions (either 2,3,4 OR 5,6,7)

Posted by: philhu

Is pdisk available on the tivo or is it in a distribution?

is mkswap on the tivo?

Posted by: srs5694

Both pdisk and mkswap are included on the MFS Tools and various other TiVo-utility boot floppies and CD-ROMs. (I've never had luck with MFS Tools 2.0 and Series 1 hard disk utilities aside from mfsbackup and mfsrestore because of byte-swapping issues, so I use other TiVo-utility systems if I need to use pdisk or other disk tools.) I can't find pdisk on my TiVo itself (an SAT-T60 accessed via Telnet), but there may be compiled binaries available. mkswap is available on my TiVo. Of course, as described by Robert, you'd issue these commands from an x86 PC booted to some sort of Linux distribution, such as a TiVo-utilities CD-ROM.

Posted by: philhu

Well, after all that, I open the tivo to take out the 'quantum'. I had bought a 60gig

Openned it up, it is a MAXTOR 40gig!

I did not put that drive in it, it was done at the factory! New machine, sat in a box for 1+ yrs, openned in May

So, lucky me, I have on the shelf and exact replacement Maxtor!

Posted by: Robert S

I think you'll find the Maxtor is 40027Mb too, so it would have been OK whatever.

Posted by: philhu

ok

dd a maxtor 40g to a maxtor 40g, SAME model numbers, yeilded
Not enough room on output device after 4.5 hours.

Am I right to assume that is because the input drive has a short final block since I was doing 32k chunks, and because of the sync keyword, the machine padded it with nulls and then wrote what it could and errored on the output also being short?

If that is the case, then the drive created IS good right?

I do not want to try it until I know cause I do not want the green screen of death with a 2 drive system and svr-2000

Posted by: Robert S

Did both drives get recognised as the correct sizes during the Linux boot sequence?

Posted by: philhu

yes, the first (tivo drive) needed qunlock run on it, but after re-bootup, they both were identical sizes

Posted by: Robert S

Does the number of blocks dd reported multiplied by the block size equal the size of the disk?

I would expect dd to have completed without any errors and I expect that using this drive in the TiVo will cause a problem. Perhaps you need to try again with conv=noerror,sync?

If the data set being copied isn't an integer multiple of the block size then dd will report x+y blocks in and out (presumably y is the number of bytes or 512-byte blocks in the last, partial block). The numbers should still match and you don't get the 'too small' error.

Posted by: philhu

Ok, for you dd experts....

conv=sync DOES exactly what I saw.

The drives are NOT an even multiple of 32k. The last 'block' is 16k, so the machine read the small block, reported it as such, then (a bug maybe?) it padded it to 32k and tried to write it, getting an 'out of space' error.

I've tried a few things.

No conv=sync....It shows all the full blocks, and 1 short block for both in AND out. Verifying my above theory.

Changed the copy multiple to 16k with conv=sync. Showed all full blocks on in and out display.

Bottom line: If you use sync, it looks like dd dutifully tries to pad the last block and then does report an error writing the block IF you are not writing an exact multiple of the blocksize you use.

FYI for all.

Hinsdale, you should add this bit of dd trivia to the how-to as well as the diffrent manufacturers EXACT disk sizes (40g=40027 or 40021 meg, etc).

Posted by: Ken Raeburn

I'd be careful about block sizes when using conv=sync,noerror. I think the behavior of dd when reading with that option is that if an error happens, it fills in the missing part of the block, but if it's reading in 16k or 32k chunks, it's not going to know which 512-byte sector was lost. (Assuming you don't have a long run of bad sectors in a row.)

Personally, I prefer something like:

dd obs=1M if=<olddisk> of=<newdisk> conv=sync,noerror

... so the input (slightly flaky) disk is handled one sector at a time (dd defaults to 512 byte block size, and only setting "obs" leaves the input block size small), and the output is still written in big chunks. I think that means that every good sector on the old disk will be copied to the correct position on the new disk, and I'm skeptical that using larger block sizes will give you that guarantee.

But maybe I'm just being overly paranoid....

Posted by: Robert S

Actually you're right, sorry about that. sync means 'pad all blocks to the output block size', therefore the last partial block will be expanded causing a benign overflow error.

Posted by: Ken Raeburn

Docs on my system say sync mean to pad input blocks to the input block size. I think you'd still get a partial final block in most cases if obs is much bigger than ibs. But that's okay....