From: Adrian McMenamin <adrian@newgolddream.dyndns.info>
To: linux-sh@vger.kernel.org
Subject: slab cache allocator problem?
Date: Tue, 29 Jan 2008 22:23:24 +0000 [thread overview]
Message-ID: <1201645404.6269.7.camel@localhost.localdomain> (raw)
I suspect this is my code, but I cannot see what is wrong. I am using
SLUB.
I create the cache thus:
maple_queue_cache kmem_cache_create("maple_queue_cache", 0x400, 0x20,
SLAB_HWCACHE_ALIGN, NULL);
Then allocate objects like this:
mq->recvbufdcsp = kmem_cache_zalloc(maple_queue_cache, GFP_KERNEL);
mq->recvbuf = (void *) P2SEGADDR(mq->recvbufdcsp);
And free them like this:
if (mq) {
if (mq->recvbufdcsp)
kmem_cache_free(maple_queue_cache, mq->recvbufdcsp);
kfree(mq);
But when I allocate and free them via hotplugging maple devices, I get things like this (after what appears to be a random number of hotplugs):
[ 41.512498] Maple bus device detaching at (0, 2)
[ 42.531304] Maple bus at (0, 2): Connected function 0x10
[ 42.537436] No maple driver found for this device
[ 44.527953] Maple bus device detaching at (0, 2)
[ 46.551408] Maple bus at (0, 2): Connected function 0x10
[ 46.557561] No maple driver found for this device
[ 48.547964] Maple bus device detaching at (0, 1)
[ 51.561406] Maple bus device detaching at (0, 2)
[ 53.586601] Maple bus at (0, 2): Connected function 0x10
[ 53.590137] No maple driver found for this device
[ 55.594248] Maple bus device detaching at (0, 2)
[ 57.619446] Maple bus at (0, 2): Connected function 0x10
[ 57.625583] No maple driver found for this device
[ 59.613890] Maple bus device detaching at (0, 2)
[ 61.639544] Maple bus at (0, 2): Connected function 0x10
[ 61.645684] No maple driver found for this device
[ 63.633992] Maple bus device detaching at (0, 2)
[ 66.664682] Maple bus at (0, 2): Connected function 0x10
[ 66.666407] No maple driver found for this device
[ 66.673767] Fault in unaligned fixup: 0000 [#1]
[ 66.677050] Modules linked in: nbd
[ 66.677050]
[ 66.677050] Pid : 752, Comm: udevd
[ 66.677050] PC is at kmem_cache_alloc+0x46/0xc0
[ 66.677050] PC : 8c0606a6 SP : 8c98be84 SR : 400080f0 TEA : c0007344 Not tainted
[ 66.677050] R0 : 00000000 R1 : 00000000 R2 : 8c98bed8 R3 : 00000000
[ 66.677050] R4 : 8c2343b0 R5 : 000080d0 R6 : 00007fff R7 : 8c0a09a8
[ 66.677050] R8 : 00000000 R9 : 000080d0 R10 : ffffffff R11 : 8c2343f4
[ 66.677050] R12 : 8c8860c0 R13 : 7ba3f5f8 R14 : 8c44adc0
[ 66.677050] MACH: 00000002 MACL: 00000000 GBR : 29708440 PR : 8c0a09a8
[ 66.677050]
[ 66.677050] Call trace:
[ 66.677050] [<8c0a09a8>] show_stat+0x28/0x380
[ 66.677050] [<8c081df8>] single_open+0x38/0xa0
[ 66.677050] [<8c0a0980>] show_stat+0x0/0x380
[ 66.677050] [<8c0a0d30>] stat_open+0x30/0xa0
[ 66.677050] [<8c0a0d00>] stat_open+0x0/0xa0
[ 66.677050] [<8c099b90>] proc_reg_open+0x90/0xc0
[ 66.677050] [<8c0a0d00>] stat_open+0x0/0xa0
[ 66.677050] [<8c099b98>] proc_reg_open+0x98/0xc0
[ 66.677050] [<8c062d86>] __dentry_open+0x126/0x240
[ 66.677050] [<8c099b00>] proc_reg_open+0x0/0xc0
[ 66.677050] [<8c081622>] seq_read+0x102/0x340
[ 66.677050] [<8c099794>] proc_reg_read+0x94/0xc0
[ 66.677050] [<8c081520>] seq_read+0x0/0x340
[ 66.677050] [<8c063cd8>] vfs_read+0x78/0xc0
[ 66.677050] [<8c063ef4>] sys_read+0x34/0x80
[ 66.677050] [<8c008240>] syscall_call+0xc/0x10
[ 66.677050] [<8c063ec0>] sys_read+0x0/0x80
[ 66.677050]
[ 66.677050] Process: udevd (pid: 752, stack limit = 8c98a001)
[ 66.677050] Stack: (0x8c98be84 to 0x8c98c000)
[ 66.677050] be80: 8c0a09a8 00000001 8c44ad80 00000001 8c8860c0 8c44ad80 8c44adc0
[ 66.677050] bea0: 00000000 8c081df8 8c0a0980 8c44ad80 fffffff4 8c608180 8c0a0d30 00000000
[ 66.677050] bec0: 8c44ad80 8c0a0d00 8c44ad80 8c522000 8c099b90 8c0a0d00 8c957010 8c099b98
[ 66.677050] bee0: 8c062d86 00000000 00000000 8c099b00 8c95708c 8c081622 8c44adc0 7ba3f5f8
[ 66.677050] bf00: 00007fff 00000001 8c44ad80 00000001 8c8860c0 00000000 00000000 8c44ad80
[ 66.677050] bf20: 00000000 8c98bf84 00000000 8c8860e0 8c099794 fffffffb 8c98bf84 00007fff
[ 66.677050] bf40: 7ba3f5f8 8c44ad80 8c081520 8cc039c0 8c063cd8 7ba3f5ec 00000000 0041e8a0
[ 66.677050] bf60: fffffff7 8c98bf84 7ba3f5f8 8c44ad80 8c063ef4 00007fff 7ba3f5f8 8c44ad80
[ 66.677050] bf80: 00000000 00000000 00000000 8c008240 ffffff0f 00000021 8c98bff8 8c063ec0
[ 66.677050] bfa0: 00000000 00000440 fffffff9 00000003 00000007 7ba3f5f8 00007fff 0041cb3c
[ 66.677050] bfc0: 00000007 7ba3f5f8 fffffffb 00000000 0041e8a0 00000000 7ba3f5ec 7ba3f5ec
[ 66.677050] bfe0: 2962d174 00402b22 00000001 29708440 00000002 00000000 0000004c 00000160
[ 66.703223] ---[ end trace 980183e2f79fb803 ]---
(You can see the maple code here: http://newgolddream.dyndns.info/cgi-bin/gitweb.cgi?p=.git;a=blob;f=drivers/sh/maple/maple.c;hýf3ecb57043e6e7b42d905c5c13a177c42fd569;hbÇb943a7ae92039458258da34acd233123637693 )
I really cannot see what I am doing wrong - any clues? Could it be some issue with the P2SEGADDR?
next reply other threads:[~2008-01-29 22:23 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-29 22:23 Adrian McMenamin [this message]
2008-01-31 4:19 ` slab cache allocator problem? Paul Mundt
2008-01-31 23:39 ` Adrian McMenamin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1201645404.6269.7.camel@localhost.localdomain \
--to=adrian@newgolddream.dyndns.info \
--cc=linux-sh@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.