All of lore.kernel.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: Couple of kernel tracebacks
Date: Mon, 28 Aug 2017 17:58:32 +0100	[thread overview]
Message-ID: <1503939512.32591.309.camel@linuxfoundation.org> (raw)
In-Reply-To: <157d0b98-436d-f536-b27e-d295f0ce0c90@windriver.com>

On Mon, 2017-08-28 at 08:54 -0400, Bruce Ashfield wrote:
> On 08/26/2017 06:53 PM, Richard Purdie wrote:
> > 
> > Hi Bruce,
> > 
> > We are seeing a few teething issues which seem kernel related on
> > the
> > autobuilder. The x86 lsb build saw this traceback in the logs:
> I'll start running some stress tests and see if I can get anything
> to happen.

Thanks!

> > This has happened on multiple builders and on multiple images
> > (sato,
> > sato-sdk and I think minimal). Could be the new kernel, could be
> > qemu
> > :/. If has occurred on lsb and non-lsb ppc which makes it less
> > kernel
> > version specific I guess. For some reason I keep wanting to blame
> > the
> > IDE drivers but it is using virtio. We never get any backtrace for
> > this, the log just stop dead and then we hit timeouts, it never
> > boots
> > fully in these cases. It stops after:
> It could be the virtio back end interacting in ways that we've
> never hit before.
> 
> I'll take another look at that IDE mess in 4.12 and see if the
> driver is fixable.
> 
> Is there anyway that we could do a few runs with only virtio on
> the 4.12 kernel and confirm that the hang goes away with the
> lsb configuration ? That would definitely point the finger at some
> sort of virtio interaction and force us into that IDE driver for
> a fix.

I did try booting the system with a "CONFIG_IDE is not set" from a
config fragment and confirmed I can turn IDE off at least for ppc and
it still works. I could put that in master-next and test that a bit,
see if things keep working and if any of the hangs occur? Its a pure
guess whether its related to IDE or not at this point...

> FYI: that IDE issue is already logged in kernel.org bugzilla (by
> someone else) and was reported to the mailing list. Neither the
> bug or the post got any attention at all. I also tried to fix the
> code and it is really detailed stuff that is going to take a few
> days of study to actually understand and fix.

Understandable. I can't help wonder if we shouldn't concentrate on on
dropping the IDE bits where we can?

Cheers,

Richard


      reply	other threads:[~2017-08-28 16:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-26 22:53 Couple of kernel tracebacks Richard Purdie
2017-08-28 12:54 ` Bruce Ashfield
2017-08-28 16:58   ` Richard Purdie [this message]

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=1503939512.32591.309.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=bruce.ashfield@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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.