All of lore.kernel.org
 help / color / mirror / Atom feed
From: Simon Horman <horms@verge.net.au>
To: Roland Dreier <rdreier@cisco.com>
Cc: Dan Williams <dan.j.williams@intel.com>,
	kexec@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: kexec reboot broken with ioatdma?
Date: Thu, 17 Dec 2009 09:49:12 +1100	[thread overview]
Message-ID: <20091216224912.GC16219@verge.net.au> (raw)
In-Reply-To: <ada3a3a8v1g.fsf@roland-alpha.cisco.com>

On Wed, Dec 16, 2009 at 01:32:11PM -0800, Roland Dreier wrote:
> I have a system with IOAT hardware, and rebooting with kexec fails with
> the latest 2.6.32-git kernel.  I haven't really tried earlier kernels,
> but I suspect the issue comes from the ioatdma driver being autoloaded now.
> 
> The reboot gets stuck at:
> 
>   ioatdma 0000:00:16.0: Self-test copy timed out, disabling
>   ioatdma 0000:00:16.0: Freeing 2 in use descriptors!
>   ioatdma 0000:00:16.0: Intel(R) I/OAT DMA Engine init failed
> 
> so presumably the IOAT hardware is left in a bad state that the ioatdma
> driver in the kexec'ed new kernel can't handle.
> 
> I notice that long ago, there was a commit 428ed602 ("I/OAT: fix I/OAT
> for kexec") that added a shutdown method to clean things up so kexec
> worked, and then more recently there was 4fac7fa5 ("ioat: do not perform
> removal actions at shutdown") that got rid of the shutdown hook.
> 
> I'm not sure what the correct fix is here: fix the shutdown order so
> everyone drops all references to IOAT stuff before IOAT is shutdown, or
> add some code to the ioatdma driver so it resets the hardware on startup
> so the new kernel can deal with an unspecified state.

Hi Roland,

from a kexec point of view I believe that the preferred option is the
former - shutdown the device so it can be initialised using standard paths
in the second kernel.


_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec

WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@verge.net.au>
To: Roland Dreier <rdreier@cisco.com>
Cc: linux-kernel@vger.kernel.org,
	Dan Williams <dan.j.williams@intel.com>,
	kexec@lists.infradead.org
Subject: Re: kexec reboot broken with ioatdma?
Date: Thu, 17 Dec 2009 09:49:12 +1100	[thread overview]
Message-ID: <20091216224912.GC16219@verge.net.au> (raw)
In-Reply-To: <ada3a3a8v1g.fsf@roland-alpha.cisco.com>

On Wed, Dec 16, 2009 at 01:32:11PM -0800, Roland Dreier wrote:
> I have a system with IOAT hardware, and rebooting with kexec fails with
> the latest 2.6.32-git kernel.  I haven't really tried earlier kernels,
> but I suspect the issue comes from the ioatdma driver being autoloaded now.
> 
> The reboot gets stuck at:
> 
>   ioatdma 0000:00:16.0: Self-test copy timed out, disabling
>   ioatdma 0000:00:16.0: Freeing 2 in use descriptors!
>   ioatdma 0000:00:16.0: Intel(R) I/OAT DMA Engine init failed
> 
> so presumably the IOAT hardware is left in a bad state that the ioatdma
> driver in the kexec'ed new kernel can't handle.
> 
> I notice that long ago, there was a commit 428ed602 ("I/OAT: fix I/OAT
> for kexec") that added a shutdown method to clean things up so kexec
> worked, and then more recently there was 4fac7fa5 ("ioat: do not perform
> removal actions at shutdown") that got rid of the shutdown hook.
> 
> I'm not sure what the correct fix is here: fix the shutdown order so
> everyone drops all references to IOAT stuff before IOAT is shutdown, or
> add some code to the ioatdma driver so it resets the hardware on startup
> so the new kernel can deal with an unspecified state.

Hi Roland,

from a kexec point of view I believe that the preferred option is the
former - shutdown the device so it can be initialised using standard paths
in the second kernel.


  reply	other threads:[~2009-12-16 22:49 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-16 21:32 kexec reboot broken with ioatdma? Roland Dreier
2009-12-16 21:32 ` Roland Dreier
2009-12-16 22:49 ` Simon Horman [this message]
2009-12-16 22:49   ` Simon Horman
2009-12-16 23:04   ` Roland Dreier
2009-12-16 23:04     ` Roland Dreier
2009-12-16 23:11     ` Dan Williams
2009-12-16 23:11       ` Dan Williams
2009-12-16 23:23       ` Roland Dreier
2009-12-16 23:23         ` Roland Dreier
2009-12-18 22:10         ` Dan Williams
2009-12-18 22:10           ` Dan Williams
2009-12-18 22:20           ` Roland Dreier
2009-12-18 22:20             ` Roland Dreier
2009-12-18 22:23             ` Dan Williams
2009-12-18 22:23               ` Dan Williams
2009-12-18 22:32               ` Roland Dreier
2009-12-18 22:32                 ` Roland Dreier
2009-12-19  7:34             ` Simon Horman
2009-12-19  7:34               ` Simon Horman
2009-12-16 23:36     ` Simon Horman
2009-12-16 23:36       ` Simon Horman
2009-12-16 23:42       ` Roland Dreier
2009-12-16 23:42         ` Roland Dreier
2009-12-16 23:45         ` Simon Horman
2009-12-16 23:45           ` Simon Horman

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=20091216224912.GC16219@verge.net.au \
    --to=horms@verge.net.au \
    --cc=dan.j.williams@intel.com \
    --cc=kexec@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rdreier@cisco.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.