From owner-freebsd-stable  Mon May 25 20:42:38 1998
Return-Path: <owner-freebsd-stable@FreeBSD.ORG>
Received: (from majordom@localhost)
          by hub.freebsd.org (8.8.8/8.8.8) id UAA09567
          for freebsd-stable-outgoing; Mon, 25 May 1998 20:42:38 -0700 (PDT)
          (envelope-from owner-freebsd-stable@FreeBSD.ORG)
Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97])
          by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id UAA09553
          for <freebsd-stable@freebsd.org>; Mon, 25 May 1998 20:42:32 -0700 (PDT)
          (envelope-from robinson@public.bta.net.cn)
Received: (from robinson@localhost)
	by public.bta.net.cn (8.8.5/8.8.5) id LAA02975
	for freebsd-stable@freebsd.org; Tue, 26 May 1998 11:42:26 +0800 (GMT)
Date: Tue, 26 May 1998 11:42:26 +0800 (GMT)
From: Michael Robinson <robinson@public.bta.net.cn>
Message-Id: <199805260342.LAA02975@public.bta.net.cn>
To: freebsd-stable@FreeBSD.ORG
Subject: Bug in wd driver
Sender: owner-freebsd-stable@FreeBSD.ORG
Precedence: bulk

I wrote a message related to this problem to freebsd-questions
yesterday, but upon further investigation, I have decided this is
a bug, not a feature.

I have a Tecra 510CDT (running 2.2.6-RELEASE) that suffered a
corrupted disk when the battery power failed as it was trying to
halt.  I have identified seven contiguous sectors on the disk that
cause the following problem:

 1. Any I/O access to the affected sectors will cause the following
    message:

    wd0: interrupt timeout
    wd0: status 58<rdy,seekdone,drq> error 0

    followed by seeking noises, and the following message:

    wd0: interrupt timeout
    wd0: status 50<rdy,seekdone> error 1<no_dam>

 2. After this, the process requesting the I/O will be completely
    locked, but the disk will continue to make seeking noises 
    continuously until the system is powered off.
    Other processes are able to access the affected slice/partition
    (ls, cat, etc.) without any difficulty, as long as they avoid 
    the 7 affected sectors.  Any process which requires privileged
    kernel calls (halt, ps, etc.) will lock immediately and 
    completely.

 3. Other than the two messages above, wd produces no error messages.

 4. Hard reset is the only way to recover.

I tried to work around this problem with bad144, but rapidly discovered
that bad144 is something of a bad joke in FreeBSD.  Does anyone have
any recommendations for how to fix the wd driver or otherwise recover
from this fault?

	-Michael Robinson

 

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message