Date: Wed, 31 Mar 1999 13:52:32 +0200 From: Ladavac Marino <mladavac@metropolitan.at> To: 'Darren Reed' <avalon@coombs.anu.edu.au>, Ladavac Marino <mladavac@metropolitan.at> Cc: dillon@apollo.backplane.com, rb@gid.co.uk, wilko@yedi.iaf.nl, jkh@zippy.cdrom.com, hackers@FreeBSD.ORG Subject: RE: another ufs panic.. Message-ID: <97A8CA5BF490D211A94F0000F6C2E55D097584@s-lmh-wi-900.corpnet.at>
next in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Darren Reed [SMTP:avalon@coombs.anu.edu.au] > Sent: Wednesday, March 31, 1999 1:34 PM > To: mladavac@metropolitan.at > 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 > Subject: Re: another ufs panic.. > > 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. > [ML] Okay, one is certain: it is not UFS. It might be hardware, however. In fact, I would tip on hardware especially since the amount of garbage varies. I have had exactly the same symptoms. It might as well be the particular hardware/software combination aggravated by marginal SIMMs, CPU, or motherboard in light of the fact that 2.2.8 does not show problems. It could also be a HAM radio operator in the vicinity coupled with insufficient shielding. But, it's very unlikely that it's UFS. If it is the hardware or environment, I cannot really offer any useful help--you know the rites, as well as anyone else :) /Marino > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?97A8CA5BF490D211A94F0000F6C2E55D097584>