Just hit our main server, while doing kernel compile
(producing a .deb using custom script which does quite
some usage of symlinks - hence sys_symlink() operation
is in call trace) -- that particular filesystem stopped
working, while the rest of the system was still operational.
It's 2.6.15.1 kernel running on an athlon-1.3GHz, pretty
old but pretty stable box, with ECC memory. The filesystem
in question is on top of a raid0 array out of 4 scsi drives
(it's used as a "staging area" for various temporary stuff,
incl. compiles and whatnot).
Any clues about this one?
Note it's the first time I encountered an error like this
one, but I did quite alot of kernel compiles on this box
already since last boot (I'm experimenting with Xen on
another box, this box is used as a "compiling server").
So I can hardly say the problem is "easily reproduceable".
Thanks.
/mjt
BTW... What's this strange "kernel BUG at <bad filename>:17407!" ?
I've seen similar stuff already on another machine, and it does
not look right... Also, the "[ cut here ]" line seems to be
misplaced.
Assertion failure in journal_start() at fs/jbd/transaction.c:270: "handle->h_transaction->t_journal == journal"
------------[ cut here ]------------
kernel BUG at <bad filename>:17407!
invalid operand: 0000 [#1]
Modules linked in: sr_mod cdrom ide_generic nfsd exportfs lockd nfs_acl sunrpc autofs4 quota_v2 raid0 via82cxxx ide_core raid5 xor 8139too mii crc32 rtc ext3 jbd mbcache raid1 md_mod sd_mod aic7xxx scsi_transport_spi scsi_mod
CPU: 0
EIP: 0060:[<f0868483>] Not tainted VLI
EFLAGS: 00010296 (2.6.15-i686)
EIP is at journal_start+0x63/0xc0 [jbd]
eax: 00000076 ebx: cac77748 ecx: c02933ac edx: c02933ac
esi: f0870587 edi: 0000010e ebp: 0000001f esp: c6f68d78
ds: 007b es: 007b ss: 0068
Process perl (pid: 9232, threadinfo=c6f68000 task=ea83d050)
Stack: f086eee0 f086ea02 f0870587 0000010e f086efa0 e3940a68 e7e1b920 c6f68dd4
f08e3cea e3940a68 e7e1b920 c0167a91 c6f68dd4 e3940a70 e3940a68 c0167b0b
c2ced198 c2ced190 00000080 00000080 c0167d98 00000002 00000080 c6914310
Call Trace:
[<f08e3cea>] ext3_dquot_drop+0x2a/0x60 [ext3]
[<c0167a91>] clear_inode+0xe1/0x120
[<c0167b0b>] dispose_list+0x3b/0xb0
[<c0167d98>] prune_icache+0x98/0x170
[<c0167e84>] shrink_icache_memory+0x14/0x40
[<c013f84f>] shrink_slab+0x16f/0x1d0
[<c014074a>] try_to_free_pages+0xda/0x1a0
[<c0139d37>] __alloc_pages+0x137/0x2c0
[<c0135c44>] find_or_create_page+0x84/0xa0
[<c01608de>] page_symlink+0x2e/0x124
[<f08e082f>] ext3_symlink+0x19f/0x1e0 [ext3]
[<c015f969>] vfs_symlink+0x89/0x110
[<c015fa64>] sys_symlink+0x74/0xc0
[<c0150fb2>] vfs_read+0xf2/0x150
[<c01512b7>] sys_read+0x47/0x80
[<c0102e99>] syscall_call+0x7/0xb
Code: 86 f0 b9 02 ea 86 f0 b8 a0 ef 86 f0 89 4c 24 04 bf 0e 01 00 00 be 87 05 87 f0 89 7c 24 0c 89 74 24 08 89 44 24 10 e8 6d 0e 8b cf <0f> 0b ff 43 08 89 d8 8b 5c 24 14 8b 74 24 18 8b 7c 24 1c 83 c4
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
