From owner-freebsd-hackers  Wed Mar 31  3:37:21 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from cheops.anu.edu.au (cheops.anu.edu.au [150.203.149.24])
	by hub.freebsd.org (Postfix) with ESMTP id 0F0DD15C97
	for <hackers@FreeBSD.ORG>; Wed, 31 Mar 1999 03:36:59 -0800 (PST)
	(envelope-from avalon@cheops.anu.edu.au)
Received: (from avalon@localhost)
	by cheops.anu.edu.au (8.9.1/8.9.1) id VAA10193;
	Wed, 31 Mar 1999 21:33:59 +1000 (EST)
From: Darren Reed <avalon@coombs.anu.edu.au>
Message-Id: <199903311133.VAA10193@cheops.anu.edu.au>
Subject: Re: another ufs panic..
To: mladavac@metropolitan.at (Ladavac Marino)
Date: Wed, 31 Mar 1999 21:33:59 +1000 (EST)
Cc: dillon@apollo.backplane.com, rb@gid.co.uk,
	avalon@coombs.anu.edu.au, wilko@yedi.iaf.nl, jkh@zippy.cdrom.com,
	hackers@FreeBSD.ORG
In-Reply-To: <97A8CA5BF490D211A94F0000F6C2E55D097576@s-lmh-wi-900.corpnet.at> from "Ladavac Marino" at Mar 30, 99 10:45:32 am
X-Mailer: ELM [version 2.4 PL23]
Content-Type: text
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

In some mail from Ladavac Marino, sie said:
[...]
>       Darren, this could possibly be your problem as well since you
> seem to have a lot of hardware hanging off the same power
> supply--prehaps it just cannot regulate any more.  You could test that
> by writing a known pattern to the raw device and then reading it
> back--just make sure that the tar runs on EIDE drive writing into the
> bit-bucket so that the EIDE does not spin down and that it keeps
> seeking--both actions take a lot of power.

Well....
first run, no tar on EIDE drive (just two drives now, EIDE & SCSI,
nothing else powered, which has ended up with corrupt dirs):

gawaine /usr# dd if=/dev/zero bs=16384k of=/dev/rsd0s4
dd: /dev/rsd0s4: short write on character device
dd: /dev/rsd0s4: end of device
125+0 records in
124+1 records out
2089221120 bytes transferred in 248.516462 secs (8406772 bytes/sec)

Now the interesting part!

I wrote my own program to read it back and check that all that was read
was indeed null bytes...however!

From 874627584 (0x3421c200 - 0x3421cfff) was non-null (actually garbage,
not just 0x01 or 0x02 or 0xf0, etc).  About 3572 bytes worth.

Wanting to confirm the location, I ran it again...this time 95573 bytes.

To check disk contents I adapted the program I used to read back to seek
to the above position.  No problem.  A run after that again, 85212 and
33157.

Try again with 2.2.8-STABLE (built from GENERIC):

# dd if=/dev/zero bs=16384k of=/dev/rsd0s4
dd: /dev/rsd0s4: short write on character device
dd: /dev/rsd0s4: end of device
125+0 records in
124+1 records out
2089221120 bytes transferred in 244.473397 secs (8545801 bytes/sec)

No non-zero bytes were read back using the program I wrote.

And with: # dd if=/dev/rsd0s4 bs=16384k | hexdump -x -n 2089221120
0000000    0000    0000    0000    0000    0000    0000    0000    0000
*
124+1 records in
124+1 records out
2089221120 bytes transferred in 433.489148 secs (4819547 bytes/sec)
7c86fc00
(repeated twice)

At no time during this was the hardware changed (though it's in a
somewhat state of advaced disarray).

Darren


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