public inbox for kexec@lists.infradead.org
 help / color / mirror / Atom feed
From: Andrew Vasquez <andrew.vasquez@qlogic.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Randy Dunlap <randy.dunlap@oracle.com>,
	Neil Horman <nhorman@redhat.com>,
	"kexec@lists.infradead.org" <kexec@lists.infradead.org>,
	Simon Horman <horms@verge.net.au>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Linux Driver <Linux-Driver@qlogic.com>,
	Vivek Goyal <vgoyal@redhat.com>
Subject: Re: In place kexec
Date: Fri, 30 Jul 2010 15:52:22 -0700	[thread overview]
Message-ID: <20100730225222.GA14545@plapp.qlogic.org> (raw)
In-Reply-To: <m1sk30zuis.fsf@fess.ebiederm.org>

On Fri, 30 Jul 2010, Eric W. Biederman wrote:

> "H. Peter Anvin" <hpa@zytor.com> writes:
> 
> > On 07/30/2010 09:30 AM, Eric W. Biederman wrote:
> >> 
> >>>> That said it looks like the code to do the shutdown is in
> >>>> qla2x00_remove_one so it should be too hard if someone cared to
> >>>> extract just the hardware bits.
> >>>
> >>> Charming.  Code is there, just not hooked up.
> >> 
> >> Using the .remove method in reboot is a fight a lost long ago.
> >> 
> >
> > Could you elucidate, please?
> 
> My original proposal was for device_shutdown to call the .remove
> methods as those are well exercised and tested in development. aka
> rmmod.
> 
> It was argued (with some merit) that for a system reboot we don't want
> to perform all of the subsystem registration work, to make it more
> likely that reboot -f will reboot even if there is a kernel oops.
> 
> What I proposed and unfortunately failed to write the patch for at the
> time is was to have the device remove path call shutdown before calling
> remove, so drivers wouldn't have to code it all up twice.
> 
> A lot of the disk drivers implement .shutdown these days and there aren't
> may bug reports about kexec failing.  So I would be reluctant to change
> things other than on a driver by driver basis unless I had a lot of time
> for testing etc.
> 
> It might be worth playing with adding a pci_clear_master in
> pci_device_shutdown.  It has the potential to break things like usb
> keyboards, so I would be careful.  If it doesn't break fundamental
> things like usb a pci_clear_master when shutting down devices should
> improve reliability somewhat.
> 
> And of course there is the old staple of work arounds: "rmmod <driver>"
> before calling kexec --exec.

Looking through all these emails, what's the upshot here?  Is the
expectation, for all storage drivers to starting to implement some
'minimal' level of shutdown with the hardware/firmware during the
.shutdown callback?


--
Andrew Vasquez

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

  reply	other threads:[~2010-07-30 22:52 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-28 21:57 In place kexec H. Peter Anvin
2010-07-28 22:02 ` Eric W. Biederman
2010-07-29 13:43   ` Neil Horman
2010-07-29 15:03     ` H. Peter Anvin
2010-07-29 15:06       ` Neil Horman
2010-07-29 17:51         ` H. Peter Anvin
2010-07-29 18:06           ` Eric W. Biederman
2010-07-29 18:29             ` H. Peter Anvin
2010-07-29 19:16               ` Vivek Goyal
2010-07-29 19:51                 ` Eric W. Biederman
2010-07-29 19:55                   ` Randy Dunlap
2010-07-30  3:38                     ` H. Peter Anvin
2010-07-30  4:41                       ` Eric W. Biederman
2010-07-30  5:04                         ` H. Peter Anvin
2010-07-30 16:30                           ` Eric W. Biederman
2010-07-30 16:41                             ` H. Peter Anvin
2010-07-30 18:36                               ` Eric W. Biederman
2010-07-30 22:52                                 ` Andrew Vasquez [this message]
2010-07-30 23:25                                   ` H. Peter Anvin
2010-07-30 23:40                                     ` Eric W. Biederman
2010-07-30 16:53                         ` David Woodhouse
2010-07-30 18:21                           ` Eric W. Biederman
2010-07-30 18:34                             ` Vivek Goyal
2010-07-30 18:50                               ` David Woodhouse
2010-07-30 18:56                                 ` Vivek Goyal
2010-07-30 19:17                                   ` David Woodhouse
2010-07-30 19:39                                     ` Eric W. Biederman
2010-07-30 19:46                                       ` David Woodhouse
2010-07-30 20:08                                         ` Eric W. Biederman
2010-07-30 20:15                                           ` David Woodhouse
2010-07-30 21:11                                             ` H. Peter Anvin
2010-07-30 20:42                           ` H. Peter Anvin
2010-07-30 21:18                             ` Khalid Aziz
2010-07-30 21:44                               ` Khalid Aziz
     [not found]                                 ` <20120425211512.GA8583@ldl.usa.hp.com>
2012-04-25 22:06                                   ` Vivek Goyal
2010-07-29 20:06                   ` H. Peter Anvin

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=20100730225222.GA14545@plapp.qlogic.org \
    --to=andrew.vasquez@qlogic.com \
    --cc=Linux-Driver@qlogic.com \
    --cc=ebiederm@xmission.com \
    --cc=horms@verge.net.au \
    --cc=hpa@zytor.com \
    --cc=kexec@lists.infradead.org \
    --cc=nhorman@redhat.com \
    --cc=randy.dunlap@oracle.com \
    --cc=vgoyal@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox