I have the data timeout problem for a while and for me I've narrowed it down to a particular string causing checksum failures in the tcp stuck on a particular motherboard. I spent some time going back and forth with David Miller and have so far got no where.
I can duplicate this with a 735 byte string If I stick the file with the string on any partitions they fail, and if I remove the file it works. The motherboard I'm seeing this on is an ASUS A7V133 I've built a kernel with the minimal requirements to make the machine boot. and tried every 2.4 kernel from 2.4.0 to 2.4.18-pre7. I attempted to try a 2.2 kernel but it didn't support the tulip card in the machine. also its not the network card as I've tried others. The last byte of the packet contating the 735 byte string is corrupted. The problem will go away if you use compression as the string is obviously changed before it travels over the wire. I have no idea where to go now. On Thu, Feb 07, 2002 at 12:01:03PM -0500, Joshua Baker-LePain wrote: > On Thu, 7 Feb 2002 at 11:47am, Benjamin Gross wrote > > > I've been having problems getting a successful level 0 backup from one > > of our servers. The amreport shows the following: > > > > FAILURE AND STRANGE DUMP SUMMARY: > > > > lopt /dev/hda1 lev 0 FAILED [data timeout] > > lopt /dev/hda1 lev 0 FAILED [dump to tape failed] > > > > Here are some of the FAILED AND STRANGE DUMP DETAILS: > > > > DUMP: Date of this level 0 dump: Wed Feb 6 23:22:40 2002 > > ... > > DUMP:Volume 1 started with block 1 at: Wed Feb 6 23:25:16 2002 > > ... > > DUMP 2.42% done at 1455 kB/s, finished in 3:21 > > ... > > DUMP: 61.83% done at 1543 kB/s, finished in 1:14 > > -------- > > This is were details ends. Incidently, it is about this far into the > > dump, when dump fails. > > Let me guess -- this is a Linux client with a 2.4 kernel? There have been > numerous reports of date timeouts using dump on recent distros. Without > starting that flamewar up again (sorry John!), there are two solutions, > one of which may work and one of which will work: > > 1 (may work): Upgrade your dump/restore to the latest version available > from <http://dump.sourceforge.net>. I haven't used dump > with amanda in a while, so I have no idea if this will work. > > 2 (will work): Switch your dumptype to use tar instaed. Of course you > need to decide if this solution will work for you, but > it will get rid of the data timeouts. (Incidentally, > this is what I did.) > > And, if I guessed wrong, then you need to look in your system logs for > anything strange going on with that disk.
