Re: [PATCH] byteorder+ufs upgrade (was Re: UFS Problems in 2.1.116p1)

Maciej W. Rozycki (macro@ds2.pg.gda.pl)
Wed, 19 Aug 1998 21:46:28 +0200 (MET DST)


This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.

---559023410-1804928587-903555988=:15069
Content-Type: TEXT/PLAIN; charset=US-ASCII

On 19 Aug 1998, Francois-Rene Rideau wrote:

> shirsch@adelphia.net (Steven N. Hirsch) writes:
> > On Mon, 17 Aug 1998, Maciej W. Rozycki wrote:
> >> UFS (Ultrix and Digital Unix) CD-ROMs worked perfectly with the previous
> >> read-only implementation of the filesystem. E.g. using 2.1.106.
> >
> > Can someone familiar with UFS internals take a look and see what's broken?
> >
> > Even if it is no longer possible (for whatever reason) to read DEC CDs, a
> > kernel lockup is not acceptable.
>
> Would you perchance be mounting a little-endian FS (DEC stuff looks like so)
> on a big-endian machine? By proof-reading the driver, I found that Daniel
> inserted an "optimization" that turns out to be a bad lack-of-swab bug
> in that case.
>
> My patch follows in .gz.uu; should be available as
> http://www.tunes.org/~fare/files/bu-2.1.116.patch.gz
> Most of it is just facelift: comments added or spell-checked.
> The only real code change is a bug fix in fs/ufs/super.c,
> at the place the variable swab is initialized (look for `UFS_MAGIC').
>
> I hope this fixes your problem.
> I'm not really proficient enough in UFS to otherwise correct deep semantic
> bugs in Daniel's code, but at least it *looks* quite cleanly written to me.

Hi,

I have no way to test your patch on a big-endian machine. However, I
tested it on an i386 machine using an Ultrix UFS CD and it does not
eliminate the lockup.

Attached, there is a patch that eliminates the lockup in a hopefully
correct way (the CD contains an 8kB-long superblock). Unfortunately, it
does not allow the CD to be mounted. Apparently there is something wrong
with the code which processes cylinder groups.

I have an image of a UFS floppy that was created using Digital Unix tools
and it mounts almost correctly ("can't grok fs_clean 0x3").

Hope this will clarify the problem somewhat.

Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

---559023410-1804928587-903555988=:15069 Content-Type: APPLICATION/octet-stream; name="patch-2.1.116-ufs.gz" Content-Transfer-Encoding: BASE64 Content-ID: <Pine.GSO.3.96.980819214628.15069B@delta.ds2.pg.gda.pl> Content-Description:

H4sIAAAAAAACA42OUWvCMBSFn5NfcR83sltNFNd2TOoeRfYyho+lrUkN1lZ6 zSaC/30xDoZDxh4uycn5Ts5dWWMAHSD2unI92Q/t763+RGMbDY1t3QFVJCMp J9G2qPpuYGjg/JDb6T6qrpFfJkfEf/zBlnoFc9eASmA4SocqHUuQSRJzIcSf BSE5c7WnQclUqlQ+XpJZBqjG8cMExPmIIcs4MObKNTzD6/ti8RQk7SxOKTfb gjbeeFvOXkbqzlEpcWq+3++vUVpbs7/FBsPDgrGy6apNTvaoPfiT9DrYYfv8 JkTlhfKNdbfvoKgL257liQP/AudObGauAQAA ---559023410-1804928587-903555988=:15069--

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html