Re: 2.5.60-bk pdflush oops.

--==_Exmh_1882242768P
Content-Type: text/plain; charset=us-ascii

> Looking back through the logs, this also this bizarre snippet during boot:-
> 
> Feb 13 20:30:24 mesh kernel: Checking if this processor honours the WP bit ev
en in supervisor mode... Ok.
> Feb 13 20:30:24 mesh kernel: Call Trace:
> Feb 13 20:30:24 mesh kernel:  [<c014a8b4>] kmem_cache_alloc+0x134/0x140
> Feb 13 20:30:24 mesh kernel:  [<c014916f>] kmem_cache_create+0xbf/0x5a0
> Feb 13 20:30:24 mesh kernel:  [<c0105000>] _stext+0x0/0x30
> Feb 13 20:30:24 mesh kernel: 
> Feb 13 20:30:24 mesh kernel: Dentry cache hash table entries: 16384 (order: 5
, 131072 bytes)

I caught this one too:

Memory: 255056k/262024k available (2010k kernel code, 6248k reserved, 895k data,
 104k init, 0k highmem)
Debug: sleeping function called from illegal context at mm/slab.c:1618
Call Trace:
 [<c0135353>] kmem_cache_alloc+0x51/0x55
 [<c013490f>] kmem_cache_create+0x6c/0x448
 [<c0105000>] _stext+0x0/0x22

Security Scaffold v1.0.0 initialized
Dentry cache hash table entries: 32768 (order: 6, 262144 bytes)

So it's after test_wp_bit() is called, and before security_scaffolding_startup().

Interesting that you didn't get the 'sleeping function called' message?

--==_Exmh_1882242768P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Exmh version 2.5 07/13/2001

iD8DBQE+TArIcC3lWbTT17ARAuMBAJ4jY7EAc13HJs1u9t19ClfHt2F5qwCg37Dy
SZm41D7UMM4r6ChAG/xlMA0=
=kS0L
-----END PGP SIGNATURE-----

--==_Exmh_1882242768P--