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
next prev parent 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