Hi Urban,
You seem to be the one to mail this stuff to.
Just came across an smbfs bug in 2.5.58-mm1 compiled with slab-debugging
but without preempt which I've been running for a while.
I was playing an mp3 from a samba server and suddenly the music stopped,
I tried pinging the server and it responded, then I tried stopping the
playback in xmms and then pressing play again. At first nothing happened
but after a few seconds xmms died and I got this in my kernel-log (the
machine appears to still be stable, writing this mail on it):
I'm not sure when these two messages appeared, but they seem related to
the crash and they weren't there when I ran dmesg a few hours earlier.
smb_get_length: Invalid NBT packet, code=96
smb_add_request: request [d023664c, mid=1802201963] timed out!
------------[ cut here ]------------
kernel BUG at mm/slab.c:1632!
invalid operand: 0000
CPU: 0
EIP: 0060:[<c01332d3>] Not tainted
EFLAGS: 00010202
EIP is at cache_alloc_debugcheck_after+0xc3/0xe0
eax: 00000001 ebx: d0236648 ecx: 00000000 edx: 000000f4
esi: ebd8d9c4 edi: 000001d0 ebp: 00000000 esp: c4e77c00
ds: 007b es: 007b ss: 0068
Process xmms (pid: 15113, threadinfo=c4e76000 task=c4c28100)
Stack: ebd8d9c4 d0236648 00000058 ebd8d9c4 00000246 c01323a6 ebd8d9c4 000001d0
d0236648 e81b7bdc 00000000 00001000 eeadbeaa ebd8d9c4 000001d0 6b6b6b6b
d0236658 00000000 00000000 c4c28100 e81b7bdc fffffff4 00000042 eeadbf60
Call Trace:
[<c01323a6>] kmem_cache_alloc+0x56/0x80
[<eeadbeaa>] smb_do_alloc_request+0x2a/0x11524180 [smbfs]
[<eeadbf60>] smb_alloc_request+0x30/0x115240d0 [smbfs]
[<eead445f>] smb_proc_open+0x3f/0x1152bbe0 [smbfs]
[<eead3e73>] smb_request_ok+0x33/0x1152c1c0 [smbfs]
[<eead4650>] smb_open+0xf0/0x1152baa0 [smbfs]
[<eeadadbb>] smb_readpage_sync+0x8b/0x115252d0 [smbfs]
[<eeadaed5>] smb_readpage+0x25/0x11525150 [smbfs]
[<c0130c91>] read_pages+0xe1/0x130
[<c013112c>] __do_page_cache_readahead+0xbc/0x110
[<c0130d23>] do_page_cache_readahead+0x43/0x50
[<c0130e7e>] page_cache_readahead+0x14e/0x190
[<c012beeb>] do_generic_mapping_read+0xbb/0x3c0
[<c012c230>] file_read_actor+0x0/0xf0
[<c012c4f4>] __generic_file_aio_read+0x1d4/0x210
[<c012c230>] file_read_actor+0x0/0xf0
[<c012c63e>] generic_file_read+0x8e/0xb0
[<c010abe5>] do_IRQ+0xc5/0xd0
[<c0109570>] common_interrupt+0x18/0x20
[<c01159ab>] do_schedule+0x17b/0x2b0
[<eeadb240>] smb_file_read+0x80/0x11524e40 [smbfs]
[<c014525e>] vfs_read+0xbe/0x130
[<c01454fe>] sys_read+0x3e/0x60
[<c0109403>] syscall_call+0x7/0xb
Code: 0f 0b 60 06 8f b6 25 c0 8b 46 34 e9 54 ff ff ff 8d b6 00 00
mm/slab.c :
(line 1632 marked with ^^^^^^)
(slab-debugging is enabled)
static inline void *
cache_alloc_debugcheck_after(kmem_cache_t *cachep,
unsigned long flags, void *objp)
{
#if DEBUG
if (!objp)
return objp;
if (cachep->flags & SLAB_POISON)
if (check_poison_obj(cachep, objp))
BUG();
^^^^^^
if (cachep->flags & SLAB_RED_ZONE) {
/* Set alloc red-zone, and check old one. */
if (xchg((unsigned long *)objp, RED_ACTIVE) !=
RED_INACTIVE)
slab_error(cachep, "memory before object was "
"overwritten");
if (xchg((unsigned long *)(objp+cachep->objsize -
BYTES_PER_WORD), RED_ACTIVE) != RED_INACTIVE)
slab_error(cachep, "memory after object was "
"overwritten");
objp += BYTES_PER_WORD;
}
if (cachep->ctor && cachep->flags & SLAB_POISON) {
unsigned long ctor_flags = SLAB_CTOR_CONSTRUCTOR;
if (!flags & __GFP_WAIT)
ctor_flags |= SLAB_CTOR_ATOMIC;
cachep->ctor(objp, cachep, ctor_flags);
}
#endif
return objp;
}
I'm not sure how to reproduce this so I hope you know what might be
going on :)
-- /MartinNever argue with an idiot. They drag you down to their level, then beat you with experience. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Feb 15 2003 - 22:00:48 EST