LINUX.IE, website of the Irish Linux Users' Group
Tux rules!

   
Home
New Users
Articles
Download
Projects
Community
Vendors

  Print Version
Email to...
 
Archives:


planetILUG

Recent News

News Archive


Join the
ILUG
on FaceBook


Join the
ILUG
on LinkedIn


Join the
ILUG SETI
Group



















 
 :: Mailing Lists

[ILUG] Device driver debugging

[ILUG] Device driver debugging

Mel mel at csn.ul.ie
Mon Oct 15 12:57:15 IST 2001


On Mon, 15 Oct 2001, Mark Dennehy wrote:

> Ref:[Dave Airlie, Mon, 15/10/01 @ 10:10 +0100]
> > get kgdb up and running and get another PC to act as a debug terminal..
> > of course the oops is useless without having been run through ksymoops..
> > you can manually debug it using System.map yourself...
>
> Ich, that'd be like pulling your toenails out with your teeth
> through the ball of your foot :(
>

not that bad, but it's a silly exercise. Run oops through ksymoops and
it'll be much easier to figure out what the hell is going wrong

> I've figured out what was happening - a simple buffer overrun
> which was hidden because the overrun was somehow getting
> whatever code ran after init_module. :(

It might be worth your while enabling SLAB_DEBUG_SUPPORT in mm/slab.c . In
2.4, this was changed to CONFIG_SLAB_DEBUG but I think it may be the same
thing, I don't have time to decipher 2.2.19's slab code to confirm but I
think it behaves kinda similar in this case

What CONFIG_SLAB_DEBUG does in 2.4 at least is add support for
SLAB_RED_ZONE and SLAB_POISON . SLAB_POISON poisons new objects in the
slab with a known test pattern for checking access to uninitialised
fields. SLAB_RED_ZONE pads one word either side of new objects with a
known test pattern to catch buffer overruns.

This is most useful when you are using the slab allocator for your own
caches but as kmalloc uses a cache of various sized memory chunks (see
/proc/slabinfo and you'll see them), the same ***may*** hold true. If you
overrun, you should see a message along the line of "Bad front redzone" in
2.2.19 and just BUG() is called on 2.4.9 during kmem_cache_free.
Unfortunatly, by then it may be too late but at least you'll be told that
memory was messed up due to overruns if you are luckly :-)

Disclaimer: I'm very new to looking at the slab allocator. I haven't
actually tested any of this, it based on simply reading the code and what
I suspect happens but don't actually know for a fact. It's quiet possible
I'm talking utter shit and way off the mark

-- 
Mel Gorman, President UL Computer Society
http://www.csn.ul.ie/~mel





More information about the ILUG mailing list
Read this without the formatting.
                                                                                                    

 

Hosted by HEAnet


Maintained by the ILUG website team. The aim of Linux.ie is to support and help commercial and private users of Linux in Ireland. You can display ILUG news in your own webpages, read backend information to find out how. Networking services kindly provided by HEAnet, server kindly donated by Dell. Linux is a trademark of Linus Torvalds, used with permission. No penguins were harmed in the production or maintenance of this highly praised website. Looking for the Indian Linux Users' Group? Try here. If you've read all this and aren't a lawyer: you should be!
RSS Version
Powered by Dell