All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pedro Francisco <pedrogfrancisco@gmail.com>
To: Vegard Nossum <vegard.nossum@gmail.com>
Cc: me@bobcopeland.com, "John W. Linville" <linville@tuxdriver.com>,
	linux-kernel@vger.kernel.org, linux-wireless@vger.kernel.org,
	mickflemm@gmail.com
Subject: Re: ath5k misbehaving affecting other kernel parts unrelated?
Date: Wed, 28 Apr 2010 22:52:07 +0100	[thread overview]
Message-ID: <201004282252.07424.pedrogfrancisco@gmail.com> (raw)
In-Reply-To: <201004241828.37489.pedrogfrancisco@gmail.com>

A Sábado, 24 de Abril de 2010 18:28:36 Pedro Francisco escreveu:
-snip 
> I get an error booting as if I'd forgotten to compile my disk's controller;
-snip

I am now able to compile my own kernels using `make all deb-pkg' on the 
vanilla source and additional hocus-pocus to create the initramfs, after 
having finally given up on using the Debian way (make-kpkg).


A Sexta, 23 de Abril de 2010 17:37:03 me@bobcopeland.com escreveu:
-snip
> Advice for debugging: turn on slub/slab debug options, and possibly
> kmemcheck.  kmemcheck was very helpful for me last time I had such
> a corruption issue.

I can't seem to find the "kmemcheck: trap use of uninitialized memory" option 
in make menuconfig, section Kernel Hacking, though a search shows it should be 
there.

Will it be useful if I do such tests now that I've opened a bug report with 
data from slab_debug?
If so, how can I enable such feature?

P.S.: considering I'm just planning on using the kernel for the tests, I don't 
bother enabling options which hurt interactivity, as long as a terminal works 
well.

Thanks again,
-- 
Pedro

  parent reply	other threads:[~2010-04-28 21:52 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-23  7:06 ath5k misbehaving affecting other kernel parts unrelated? Pedro Francisco
2010-04-23 13:48 ` John W. Linville
2010-04-23 16:37   ` me
2010-04-23 16:43     ` Maciej Żenczykowski
2010-04-24  8:59       ` Pedro Francisco
2010-04-24  8:56     ` Pedro Francisco
2010-04-24 12:05       ` me
2010-04-24 12:09       ` Vegard Nossum
2010-04-24 17:28         ` Pedro Francisco
2010-04-25 19:22           ` me
2010-04-25 20:29             ` Jiri Slaby
2010-04-25 21:24               ` Pedro Francisco
2010-04-27 11:04                 ` Pedro Francisco
2010-04-28 21:52           ` Pedro Francisco [this message]
2010-04-29  7:17             ` Vegard Nossum
2010-04-29 10:25               ` Pedro Francisco
2010-04-23 19:13 ` Dan Carpenter
2010-04-24  9:27   ` Pedro Francisco
2010-04-24 12:13     ` Dan Carpenter
2010-04-24 13:13       ` Pedro Francisco

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=201004282252.07424.pedrogfrancisco@gmail.com \
    --to=pedrogfrancisco@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=me@bobcopeland.com \
    --cc=mickflemm@gmail.com \
    --cc=vegard.nossum@gmail.com \
    /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.