mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hans-Peter Jansen <hpj@urpla.net>
To: Nicholas Lee <nj.lee@plumtree.co.nz>, linux-kernel@vger.kernel.org
Cc: Jani Forssell <jani.forssell@viasys.com>,
	Ville Herva <vherva@niksula.hut.fi>
Subject: Re: 2.4.18-pre3-ac2 still having problems (was Disk corruption - Abit KT7, 2.2.19+ide patches)
Date: Sat, 26 Jan 2002 14:10:37 +0100	[thread overview]
Message-ID: <20020126131037.AA8BE13E3@shrek.lisa.de> (raw)
In-Reply-To: <20020115202302.GA598@inktiger.kiwa.co.nz> <20020124224017.GF555@inktiger.kiwa.co.nz>
In-Reply-To: <20020124224017.GF555@inktiger.kiwa.co.nz>

On Thursday, 24. January 2002 23:40, Nicholas Lee wrote:
> Just a follow up on the previous report.
>
> Replace the kernel with 2.4.18-pre3-ac2 which includes the recent ATA
> driver from Andre Hedric.  NIC was moved from slot 3.
>
>
> nic@hoppa:~$ cat /proc/ide/drivers
> ide-cdrom version 4.59
> ide-disk version 1.12
>
>
> Everything seemed to be running smoothly.
>
> I performed the stress test mentioned here:
> http://marc.theaimsgroup.com/?l=linux-kernel&m=101059003125783&w
> with the added complication of ping flooding and being ping flooded.
>
>
> nic@hoppa:~$ sudo cat /dev/hda > /dev/null & sudo ping -f -s 64000 inktiger
> [1] 445
> PING inktiger.kpac.co.nz (192.168.9.108): 64000 data bytes
> ...........................................................................
>............................................................................
>............................................................................
>............................................................................
>............................................................................
>.......... --- inktiger.kpac.co.nz ping statistics ---
> 406 packets transmitted, 16 packets received, 96% packet loss
> round-trip min/avg/max = 258.3/695.8/1783.5 ms
> nic@hoppa:~$ uname -a
> Linux hoppa 2.4.18-pre3-ac2 #3 Wed Jan 23 10:48:41 NZDT 2002 i686 unknown
>
>
>
> I was going to say "Stable as a rock again", but I thought to soon.
>
> Five mintues later, down it goes:
>
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=28086092,
> sector=2960368 end_request: I/O error, dev 03:07 (hda), sector 2960368
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=28086108,
> sector=2960376 end_request: I/O error, dev 03:07 (hda), sector 2960376
> hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
> hda: dma_intr: error=0x40 { UncorrectableError }, LBAsect=28086108,
> sector=2960384 end_request: I/O error, dev 03:07 (hda), sector 2960384
>
> Start filling up the console.
>
> Lucky I've got ext3 I think. Nope, as soon as the reboot gets to that
> partition the above messages start filling up the console again.
>
> fsck -c /dev/hda7 only makes things worse. Looks like I'll just have to
> deep six that whole part of the drive.
>
> Power reset - to reset the HD IDE bus - doesn't seem to help matters
> either. Looks like the low-level format part of the drive might be
> corrupted.
>
>
> Note: /dev/hda7 is the /var mount point. I've noted before that often
> problems with the drive and related to CUPS spool events. Network and
> disk IO at the same time.
>
>
> Looks like that part of the drive is completely toasted. I wonder where
> I sould send the bill too. I'm definitely thinking that I should not
> even consider AMD/VIA solutions near core servers.
>
>
> Default settings on boot:
> [nic@inktiger:~] cat hdparm.log
>
> /dev/hda:
>  multcount    = 16 (on)
>  I/O support  =  1 (32-bit)
>  unmaskirq    =  1 (on)
>  using_dma    =  1 (on)
>  keepsettings =  0 (off)
>  nowerr       =  0 (off)
>  readonly     =  0 (off)
>  readahead    =  8 (on)
>  geometry     = 3737/255/63, sectors = 60046560, start = 0
>  busstate     =  1 (on)

While you not mentioning your drive manufacturer, I bet for
IBM (you know, what this acronym stands for: idiots build...)
Actually not all of them, but definitely those, who try to engender
ide harddisks. 

If my bet is right, search for discussions on ibm hd corruption here.

Basically, if you powercycle your system during a write operation,
affected blocks will return hard read errors on future access.

The likelyhood for affecting /var is high. Here it happened
during a procmail delivery of lkml messages.

Try to return those drives to your dealer.

Hans-Peter

  reply	other threads:[~2002-01-26 13:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-15 20:23 Disk corruption - Abit KT7, 2.2.19+ide patches Nicholas Lee
     [not found] ` <20020115205116.GH51648@niksula.cs.hut.fi>
     [not found]   ` <20020115211032.GC598@inktiger.kiwa.co.nz>
2002-01-15 21:37     ` Nicholas Lee
     [not found]     ` <20020115214049.GI51648@niksula.cs.hut.fi>
2002-01-15 22:02       ` Nicholas Lee
2002-01-15 22:59         ` Ed Sweetman
2002-01-15 23:13           ` Nicholas Lee
2002-01-16  7:07           ` Ville Herva
2002-01-19  2:40             ` Nicholas Lee
2002-01-19 10:44               ` Ville Herva
2002-01-24 22:40 ` 2.4.18-pre3-ac2 still having problems (was Disk corruption - Abit KT7, 2.2.19+ide patches) Nicholas Lee
2002-01-26 13:10   ` Hans-Peter Jansen [this message]
2002-01-25  1:14 ` Disk corruption - Abit KT7, 2.2.19+ide patches Tim Moore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20020126131037.AA8BE13E3@shrek.lisa.de \
    --to=hpj@urpla.net \
    --cc=jani.forssell@viasys.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nj.lee@plumtree.co.nz \
    --cc=vherva@niksula.hut.fi \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®