From owner-freebsd-questions Sat May 5 23:58:43 2001 Delivered-To: freebsd-questions@freebsd.org Received: from smtppop3pub.verizon.net (smtppop3pub.gte.net [206.46.170.22]) by hub.freebsd.org (Postfix) with ESMTP id D6B4937B423 for ; Sat, 5 May 2001 23:58:32 -0700 (PDT) (envelope-from j.bol@gte.net) Received: from Ath (cable7-023.gte.net [24.96.36.23]) by smtppop3pub.verizon.net with SMTP ; id BAA675561 Sun, 6 May 2001 01:53:27 -0500 (CDT) From: "John Bolster" To: "Ted Mittelstaedt" , "Freebsd-Questions@Freebsd. Org" Subject: RE: ftp file corruption SOLVED Date: Sun, 6 May 2001 03:00:40 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Importance: Normal In-Reply-To: <002c01c0cc7c$64ba0ee0$1401a8c0@tedm.placo.com> Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG As a result of going through some of Ted's suggestions here, I changed the timing of the memory in the BIOS from 10ns to 12ns, even though I shouldn't have had to. This appears to have stopped the file corruption completely and also stopped all the random crashes. Thanks Ted. Best, John Bolster > -----Original Message----- > From: Ted Mittelstaedt [mailto:tedm@toybox.placo.com] > Sent: Tuesday, April 24, 2001 1:07 AM > To: John Bolster; Freebsd-Questions@Freebsd. Org > Subject: RE: ftp file corruption > > > That sounds to me very much like data error in your computer. > Here's some possible reasons: > > 1) bad cache ram so when data is passed through the CPU from > core to peripherals it gets trashed > > 2) bad main ram so when data is passed through the CPU from > core to peripherals it gets trashed. BIOS settings in mboard > that run the ram too fast or with wrong RAS/CAS speeds > > 3) bus set to wrong multiplier and it's running too fast (isa > bus should not be run past 8Mhz) > > 4) CPU set to wrong multiplier (check jumpers) > > 4a) CPU overclocked > > 4b) CPU running too hot > > 5) CPU set to too low or high a voltage > > 6) hardware conflict between 2 peripheral cards that causes > data transfers on the bus to fail or be trashed > > 7) failing IDE disk drive electronics that trash data that > is coming off or going into the disk > > 8) failing electronics in network adapter. > > 9) network card cannot do full-duplex and hub thinks it can > > Some computers (like Compaq) have very good system diagnostics > disks that you can run for hours on the system to see if > there's problems. Something's badly wrong here. Can you > pull the disk out temporairly and put it into another system > and see if the problems in the new system go away? > > Ted Mittelstaedt tedm@toybox.placo.com > Author of: The FreeBSD Corporate Networker's Guide > Book website: http://www.freebsd-corp-net-guide.com > > > >-----Original Message----- > >From: owner-freebsd-questions@FreeBSD.ORG > >[mailto:owner-freebsd-questions@FreeBSD.ORG]On Behalf Of John Bolster > >Sent: Monday, April 23, 2001 10:31 AM > >To: Freebsd-Questions@Freebsd. Org > >Subject: ftp file corruption > > > > > >Hello All, > > > >I am running FBSD 4.1 release with ftpd. Transferring small files was no > >problem, but I have found repeatedly that once a file gets larger, if I > >upload it to the server then download it from the server, what I > >get back is > >the right file size, but corrupted. By corrupted, I mean that some of the > >pictures in a large Word document will have gone black, or the > >install files > >for a program will claim to have a crc error. > > > >I am conducting these tests from a Windows 98 machine using Internet > >Explorer. I also tried it with Cute FTP, and many other ftp programs. The > >corruption occurs also from machines directly connected to the server > >through a LAN. > > > >After trying unsuccessfully for hours to send and receive an uncorrupted > >version of one file, I tried ftping it to a Pair Networks server > and got it > >back uncorrupted the first time. This makes me think that ftp is > >meant to be > >stable enough to do this and that there's a problem on my server. > > > >Other oddities I've noticed are: > > > >>From time to time when I look in the anonymous ftp directories, I find a > >directory in /incoming called /incoming/incoming, or /incoming/pub, or > >/incoming/bin, and this directory contains ten directories, > named 0 through > >9, and each of these contains ten directories named 0 through 9. Since > >they're all empty, I've deleted them each time. > > > >I get messages from the kernel that processes exited on signal 11 or 4 > >(mostly 11). I copied the following snippets from my daily > security output > >emails (and one from the monthly one) between 4/1/01 and 4/23/01: > > > >alf.clearwateracademy.org kernel log messages: > >> pid 1756 (dump), uid 0: exited on signal 4 > > > >gzcat: /usr/share/man/man1/make.1.gz: unexpected end of file > > > >gzcat: /usr/share/man/man1/tip.1.gz: invalid compressed data--crc error > >Segmentation fault - core dumped > > > >alf.clearwateracademy.org kernel log messages: > >> pid 238 (httpd), uid 65534: exited on signal 11 > > > >alf.clearwateracademy.org kernel log messages: > >> pid 240 (httpd), uid 65534: exited on signal 11 > >> pid 13206 (perl), uid 0: exited on signal 11 (core dumped) > > > >checking for passwordless accounts: > >awk: cmd. line:1: fatal error: internal error > >Abort trap - core dumped > > > >Is this an undue amount of errors for that time period? > > > >I'm also not sure what I'm to do when I see that something > dumped core. So > >far, the only thing I've been able to do is to sometimes find > the name.core > >file and delete it so that I don't get file system full messages. > > > >Any help would be appreciated. > > > >Thanks, > > > >John Bolster > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-questions" in the body of the message > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message