Date: Mon, 04 Aug 1997 18:33:59 -0700 (PDT) From: Simon Shapiro <Shimon@i-Connect.Net> To: filo@yahoo.com, freebsd-scsi@freebsd.org Subject: RE: strange difference between DPT and Adaptec Message-ID: <XFMail.970804183359.Shimon@i-Connect.Net> In-Reply-To: <199708050016.RAA28126@ns2.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ I hope you do not mind me forwarding this to the FreeBSD SCSI list ] Hi David Filo; On 05-Aug-97 you wrote: > This problem is a bit strange. I've got a disk (fujitsu narrow, > running 2.2 with 1.1.10 DPT code) that seems to work just fine with an > Adaptec 2940. If I connect the drive (just by itself) to the DPT card > it comes up fine - but there is one particular directory that if I try > to "ls" in, the machine panics with "bad dir ino at offfset 0: mangled > entry". I found this because fsck would fail on bus error (on this > paricular directory) under DPT but work fine with the 2940. Fsck should NOT fail with bus error regardless of diet. Its purpose in life is to deal with broken file systems. Right? > I've tried this in two different motherboards both of which have > worked fine otherwise with the DPT card. And in both cases DPT fails, > 2940 works fine. > > I dd'ed the entire drive onto another and that copy does not exhibit > this behavior. You probably did the dd undr the DPT. Right? > So to me it seems like maybe some marginal hardware (possibly the > drive). Although this behavior is 100% consistent which makes me > wonder. We won't be using that drive so it's not a big deal, but > thought you might like to know. If you have any clue what the problem > might be or tests you'd like me to try, let me know. Do not throw the drive away yet. See below: Now that you baught a DPT, let me tell you something :-) - Don't you hate this statement. Happened to me on several cars I baught. Joking aside, the DPT firmware, sometimes reserves one block at the start of the disk for its own purposes, and slips all LBAs by one. The theory is that it does it on ALL RAID devices and on the lowest target on the lowest bus on the first controller. The reality is that it is hard (for me) to tell when and why the firmware does that. When you dd from device to device, you basically skip the problem. Simon BTW, this sector is what allows the DPT firmware to know what RAID arrays are where and how. If you are brave, disconnect a large array, shuffle the drive (after changing target IDs and try to boot. run the dptmgr and look at the confusion. At one time, I had a RAID-1, composed of targets 8,9 on bus 0. I re-jumpered the drives to 0,1 and put them on bus zero, expecting the RAID-1 array to disappear. When booting, the BIOS reported them as b0t0u0, but FreeBSD saw them as b0t8u0. Took me few moments to figure out why ALL the kernels panicked with ``cannot mount root fs''. Moral: When moving disks form HBA to HBA, low-level format them.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.970804183359.Shimon>