From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Miller Subject: CRC32C big endian bugs... Date: Tue, 12 Feb 2008 01:23:36 -0800 (PST) Message-ID: <20080212.012336.241084860.davem@davemloft.net> References: <200802061200.14690.chris.mason@oracle.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, btrfs-devel@oss.oracle.com To: chris.mason@oracle.com Return-path: In-Reply-To: <200802061200.14690.chris.mason@oracle.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org The CRC32C implementation in the btrfs progs is different from the one in the kernel, so obviously nothing can possibly work on big-endian. This is getting less and less fun by the minute, I simply wanted to test btrfs on Niagara :-/ Here is a patch to fix that: --- vanilla/btrfs-progs-0.12/crc32c.c 2008-02-06 08:37:45.000000000 -0800 +++ btrfs-progs-0.12/crc32c.c 2008-02-12 01:19:33.000000000 -0800 @@ -91,13 +91,11 @@ static const u32 crc32c_table[256] = { * crc using table. */ -u32 crc32c_le(u32 seed, unsigned char const *data, size_t length) +u32 crc32c_le(u32 crc, unsigned char const *data, size_t length) { - u32 crc = (__force __u32)(cpu_to_le32(seed)); - while (length--) crc = crc32c_table[(crc ^ *data++) & 0xFFL] ^ (crc >> 8); - return le32_to_cpu((__force __le32)crc); + return crc; }