All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Ted Ts'o" <tytso@mit.edu>
To: Martin Steigerwald <Martin@lichtvoll.de>
Cc: linux-kernel@vger.kernel.org, Paolo Ornati <ornati@gmail.com>
Subject: Re: help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes
Date: Mon, 6 Sep 2010 22:51:10 -0400	[thread overview]
Message-ID: <20100907025110.GD6134@thunk.org> (raw)
In-Reply-To: <201009050953.52440.Martin@lichtvoll.de>

On Sun, Sep 05, 2010 at 09:53:41AM +0200, Martin Steigerwald wrote:
> 
> Quite some kernels were unbootable with an ext4 and readahead related 
> backtrace[1]. 

Unfortunately, you don't have a full backtrace in the picture which
submitted as an attachment to the bugzilla.  It shows part of the
backtrace which has an ext4 and readahead stack, yes.  But we didn't
get to see the beginning of the stack trace with the IP and the reason
for the oops.  If keyboard interrupts still work, you might try seing
if you can scroll upwards and see more of the backtrace.  Or you might
try configuring your console to use a higher resolution display so
more lines can be displayed.  Or you might try getting a serial
console.

I don't recognize the display, but the problem could just as easily be
in the block layer or in the device driver for your hard drive.
(i.e., the readahead stack calls ext4, which in turn will submit a
read request to the block device layer which then submits the request
to a device driver).

But because you keep referring it to it as an ext4/readahead related
backtrace, you may have disguised the symptom enough that people who
might recognize it as, "Oh, yeah, there was this regression in the
SATA layer", wouldn't recognize it as such from your description.
That's why it's important to be careful how you describe issues; if
you had said, I don't have a complete stack trace, and I don't have
the IP and function where the fault occurred, that might have caused
people to think a bit harder about what might be the problem, instead
of thinking to themselves, "ah, well, the ext4 and readahead parts of
the kernel aren't my problem, so I'll ignore this report".

> I am also seeking help with selecting more suitable commits to test: If 
> its a Radeon KMS related freeze and everything points at it, I think the 
> offending commit is in the first quarter of what git commit shows to me[2]. 

You do know that you can restrict a git bisect to commits that modify
a particular part of the tree, right?  e.g.,

git bisect start 2.6.34 2.6.33 -- drivers/gpu/drm/radeon

					- Ted

  parent reply	other threads:[~2010-09-07  2:51 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-31 19:53 help with git bisecting a bug 16376: random - possibly Radeon DRM KMS related - freezes Martin Steigerwald
2010-08-31 22:39 ` Ken Moffat
2010-09-01 16:10   ` Martin Steigerwald
2010-09-01 18:13     ` Ken Moffat
2010-09-01 18:47 ` Paolo Ornati
2010-09-01 19:26   ` Martin Steigerwald
2010-09-05  7:53   ` Martin Steigerwald
2010-09-05 12:20     ` Paolo Ornati
2010-09-05 13:25       ` Martin Steigerwald
2010-09-07  2:51     ` Ted Ts'o [this message]
2010-09-09 14:18       ` Martin Steigerwald
2010-09-10 11:55         ` Florian Mickler
2010-09-10 13:49           ` Martin Steigerwald
2010-09-10 15:53             ` Theodore Tso
2010-09-10 16:18               ` Martin Steigerwald

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=20100907025110.GD6134@thunk.org \
    --to=tytso@mit.edu \
    --cc=Martin@lichtvoll.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ornati@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.