Hi Greg,
On 06/12/2010 08:18, Greg Ungerer wrote:
Hi Philip,
On 26/11/10 03:32, Philip Nye wrote:
On 25/11/2010 16:46, Philip Nye wrote:
Further info on this:
On 25/11/2010 15:30, Philip Nye wrote:
I'm getting a slub crash when loading a module:
"BUG: failure at .../mm/slub.c:2771/kfree()!"
The test at this location is BUG_ON(!PageCompound(page));
This seems to occur when the kernel tries to dump my modules init
function -
if I don't mark the function __init the crash doesn't happen.
Well it didn't before, but now I've put more code in and the module is
bigger, it is crashing at the same BUG despite the __init being off.
It is crashing on "insmod" before any attempt is made to actually run
any of
the code except possibly the init function and without any debug messages
that I can catch other than the BUG itself. Could it be related to module
size? is there a limit?
This is definitely size related - as soon as the size of module.ko on
disk gets above 8191 bytes the crash happens. I have tested this by
declaring a dummy constant array within the module so by playing with
the size of the array I can change the object size without changing
anything else.
Can you do a "m68k-uclinux-size" on the module?
(One that causes a crash that is)
I tried something simple like building fat.ko and loading that:
text data bss dec hex filename
38320 342 28 38690 9722
romfs/lib/modules/2.6.37-rc4-00243-g164fb21/kernel/fs/fat/fat.ko
The file itself is 53736, and I don't see any crash (on a 5208evb,
current git tree, also configured for SLUB).
I had got around this issue by switching to SLOB. I have now recompiled with
SLUB and the problem recurs. I am using two modules which can trigger the
crash. m68k-uclinux-size gives:
text data bss dec hex filename
5853 362 84 6299 189b dmx512.ko
2628 442 360 3430 d66 wafl.ko
but as I said, in previous tests the crash seemed to relate to the raw size
of the .ko file which would trigger the BUG at 8kB exactly. These two
modules are 10927 and 8732 respectively.
Unless there is a good reason to use SLUB, I will just continue with SLOB
which is smaller. SLUB seems to be aimed at big systems with many CPUs which
is the opposite of my case - I was only using SLUB because when I last
played with them about a year ago, SLUB was the only one which worked
properly at all. I suspect this bug is probably due to some configuration
incompatibility which I am unaware of.
Philip
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
