FS#22598 - [kernel26] Crash: "kernel BUG at fs/buffer.c:3229!"

Attached to Project: Arch Linux
Opened by jackoneill (jackoneill) - Tuesday, 25 January 2011, 13:58 GMT
Last edited by Andrea Scarpino (BaSh) - Saturday, 16 April 2011, 11:02 GMT
Task Type Bug Report
Category Kernel
Status Closed
Assigned To Tobias Powalowski (tpowa)
Architecture x86_64
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:
I ran "optipng /home/blah/screenshots/foo/*.png" in one tmux window and "optipng /home/blah/screenshots/bar/*.png" in another tmux window. foo and bar each contain ~10-20 frames extracted with mplayer. Apparently one of them finished and the other optipng process was halfway done when xorg disappeared and the nice trace [1] appeared on a tty.

The filesystem mounted at /home is ext4 - this is the relevant line from fstab:
LABEL=home /home ext4 defaults,noatime,nodiratime 0 1

Since the last normal boot about a week ago, I had hibernated twice (uswsusp, swap partition), if that matters at all.

Additional info:
$ uname -a
Linux home 2.6.37-ARCH #1 SMP PREEMPT Fri Jan 7 17:32:33 CET 2011 x86_64 Intel(R) Core(TM)2 Duo CPU T5470 @ 1.60GHz GenuineIntel GNU/Linux

$ pacman -Q kernel26
kernel26 2.6.37-1
(using [testing], last -Syu was yesterday)
(I see there is kernel26 2.6.37-2 now, but the commit message [2] doesn't seem relevant to this problem)

$ pacman -Q optipng
optipng 0.6.4-1

[1] http://paste.pocoo.org/show/326594/ - extracted from kernel.log, lines 138-181
[2] http://projects.archlinux.org/svntogit/packages.git/commit/kernel26/trunk?id=55b5888f94c9bb056e730f3c70484904bee8b0c0
[3] http://paste.pocoo.org/show/326590/ - full kernel.log (also attached to this task)
   ext4-optipng-fail.log (75.2 KiB)
This task depends upon

Closed by  Andrea Scarpino (BaSh)
Saturday, 16 April 2011, 11:02 GMT
Reason for closing:  None
Additional comments about closing:  seems solved
Comment by Jan de Groot (JGC) - Wednesday, 26 January 2011, 13:58 GMT
Looks like a bug in the ext4 filesysten kernel driver. Could you run fsck on the partition that you were reading and writing from when this happened? Corrupted filesystems can cause these things, so to rule that out you should unmount and fsck your filesystem.
Comment by jackoneill (jackoneill) - Wednesday, 26 January 2011, 15:09 GMT
Umm, I rebooted the system when this happened, and there were these line printed after "Checking filesystems":
home: clearing orphan inode 261375 (uid=1000, gid=1000, mode=0100644, size=1234088)
home: clean, blah/blah files, blahblah/blahblah blocks

Does that mean an fsck was performed?
Comment by Jan de Groot (JGC) - Wednesday, 26 January 2011, 15:26 GMT
That's fsck in auto-repair mode on bootup, it just checks the journal and doesn't do further extensive examination. A normal run of fsck will take much more time.
Comment by jackoneill (jackoneill) - Wednesday, 26 January 2011, 15:28 GMT
I see. Do you recommend any fsck options in particular? I'm just not sure which to use/not use.
Comment by Jan de Groot (JGC) - Wednesday, 26 January 2011, 15:40 GMT
After unmounting the partition, run it with just the "-f" flag, without that flag it will skip the check as it appears to be clean.
Comment by jackoneill (jackoneill) - Wednesday, 26 January 2011, 16:06 GMT
I booted the latest x86_64 test iso (2011.01.24) and ran '# fsck.ext4 -f /dev/disk/by-label/home'. This is all it said:
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
home: 27374/6368608 files (3.8% non-contiguous), 20839030/25612138 blocks

That's good, right?
Comment by Jelle van der Waa (jelly) - Thursday, 14 April 2011, 20:57 GMT
is this still an issue?
Comment by jackoneill (jackoneill) - Friday, 15 April 2011, 10:46 GMT
I have not encountered this problem again but I also have not tried to run two optipng instances at the same time.

Loading...