Bug#615998: linux-image-2.6.32-5-xen-amd64: Repeatable "kernel BUG at fs/jbd2/commit.c:534" from Postfix on ext4
Maybe I am wrong here, but shouldn't the cast be to (unsigned long) or to (sector_t)?
Line 534 of commit.c:
jbd_debug(4, "JBD: got buffer %llu (%p)\n",
(unsigned long long)bh->b_blocknr, bh->b_data);
Line 64 of buffer_head.h:
sector_t b_blocknr; /* start block number */
Lines 137-143 of include/linux/types/h:
typedef u64 sector_t;
typedef u64 blkcnt_t;
typedef unsigned long sector_t;
typedef unsigned long blkcnt_t;
Is it possible he is experiencing the panic due to a bad cast in the call to jbd_debug() in fs/jbd2/commit.c? It would seem to me this should be cast to (sector_t). Any thoughts?
On Thu, Jun 23, 2011 at 2:32 PM, Moffett, Kyle D <Kyle.D.Moffett@boeing.com>
Hello again everyone,
I'm in the middle of doing some software testing on a pre-production
clone of this system using some modified software configurations and a
testing-only data volume, and I've managed to trigger this panic again.
The trigger was exactly the same; I had a bunch of queued emails from
logcheck because my TLS configuration was wrong, then I fixed the TLS
configuration and typed "postqueue -f" to send the queued mail.
Ted, since this new iteration has no customer data, passwords, keys, or
any other private data, I'm going to try to get approval to release an
exact EC2 image of this system for you to test with, including the fake
data volume that I triggered the problem on.
If not I can certainly reproduce it now by stopping email delivery and
generating a lot of fake syslog spam; I can try applying kernel patches
and report what happens.
Hopefully you're still willing to help out tracking down the problem?
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html