public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: "Adam J. Richter" <adam@yggdrasil.com>
Cc: Eric Blade <eblade@blackmagik.dynup.net>, linux-kernel@vger.kernel.org
Subject: Re: Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices
Date: 13 Oct 2002 15:27:39 -0600	[thread overview]
Message-ID: <m1elaum3lg.fsf@frodo.biederman.org> (raw)
In-Reply-To: <1034538718.1215.4.camel@cpq>

Eric Blade <eblade@blackmagik.dynup.net> writes:

> On Sun, 2002-10-13 at 15:24, Adam J. Richter wrote:
> > 	linux-2.5.42 had an annoying new behavior.  When I would
> > try to do a warm reboot, it would spin down the hard drives, which
> > just made the reboot take longer and gave the impression that a
> > halt or poweroff was in progress.
> > 
> > 	At first, I suspected IDE, but I think the new behavior in IDE
> > of spinning down the hard drives on suspend is correct.  The problem
> > is that the warm reboot system call is trying to suspend all of the
> > devices before a warm reboot for no reason.


There is a very good reason for calling the driver->remove() function
on a reboot so that we place the devices in a consistent state.  And
stop any on going DMA etc.  If the ide module spins down disks when
you remove it that is a little odd.

>  We already have a reboot
> > notifier chain that drivers can use to register code that has to be
> > run in order to safely reboot or halt.  

The reboot notifier call chain, is highly underused, and all of the drivers
already have the code they need in their remove function.

> I am not talking about
> > eliminating that.  I am only talking about the soft reboot putting
> > devices into a power saving mode that is allowed to take a long
> > recovery time, especially given that the reboot is likely to want to
> > talk to every hardware device connected to the system.

If 
driver->remove() 
does that it is an issue with that device driver.

> > 	Anyhow, here is the patch.  As far as I can tell, there is no
> > delegated mainainer for kernel/sys.c, so I am sending this to
> > linux-kernel and I will resend it to Linus later if nobody points me
> > to another maintainer to go through and there are no complaints.
> 
> Adam,
>   I'm not sure the proper thing to do is necessarily remove the
> device_shutdown() call.  

I am certain it is.  

> I did the changes to the device_shutdown()
> function, but as far as I can tell, it should not have changed any
> behavior like that - all I did was re-work the logic a bit.  In any
> case, what I did submit to the mailing list was absent a small piece of
> code (a change to device.h), and the person who forwarded it onto Linus
> (thank you!) did make a change to make it compile without that.

Hmm.  Does SUSPEND_POWER_DOWN have noticeably different behavior?

>   Please try this patch to the base 2.5.42 code, and let me know if this
> returns it to the previous behavior?

How can this affect device_shutdown()?  
If POWER_DOWN is used in different places I can see the desire for the change.
But I don't even see why we would want this.

Oh, and thank you for the code by the way.  I can finally write a correct
version of kexec, and expect the device drivers to clean themselves up
properly.

Eric

  reply	other threads:[~2002-10-13 21:23 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-13 19:24 Patch: linux-2.5.42/kernel/sys.c - warm reboot should not suspend devices Adam J. Richter
2002-10-13 19:51 ` Eric Blade
2002-10-13 21:27   ` Eric W. Biederman [this message]
2002-10-13 22:52 ` Andries Brouwer
2002-10-14  0:30   ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2002-10-13 22:14 Adam J. Richter
2002-10-13 22:31 ` Russell King
2002-10-13 23:49 ` Eric W. Biederman
2002-10-15 16:35 ` Patrick Mochel
2002-10-15 20:04   ` Mikael Pettersson
2002-10-19 18:30   ` Eric W. Biederman
2002-10-20  9:47     ` Eric W. Biederman
2002-10-13 23:10 Adam J. Richter
2002-10-13 23:15 ` Russell King
2002-10-14  0:03   ` Eric W. Biederman
2002-10-13 23:54 ` Eric W. Biederman
2002-10-13 23:59 Adam J. Richter
2002-10-14  0:07 ` Eric W. Biederman
2002-10-14  5:38   ` Eric Blade
2002-10-14 15:28     ` Eric W. Biederman
2002-10-15  4:34       ` Eric Blade
2002-10-14 15:25 Adam J. Richter
2002-10-14 16:44 ` Eric W. Biederman
2002-10-14 17:48   ` Richard B. Johnson
2002-10-14 19:28     ` Eric W. Biederman
2002-10-14 20:17       ` Richard B. Johnson
2002-10-14 18:41 Adam J. Richter
2002-10-14 20:05 ` Eric W. Biederman
2002-10-15  4:55   ` Eric Blade
2002-10-16  8:01 ` Pavel Machek
2002-10-15  2:53 Adam J. Richter
2002-10-15 16:59 ` Eric W. Biederman
2002-10-15 18:54 Adam J. Richter
2002-10-15 19:52 Adam J. Richter
2002-10-16 12:13 ` Eric W. Biederman
2002-10-17  1:50 Adam J. Richter
2002-10-17  9:08 ` Eric W. Biederman
2002-10-20  7:01 Adam J. Richter
2002-10-20  9:17 ` Eric W. Biederman
2002-10-20 20:43   ` Patrick Mochel
2002-10-20 23:57     ` Eric W. Biederman
2002-10-21 17:13       ` Patrick Mochel
2002-10-21 20:56 Adam J. Richter
2002-10-22  4:28 ` Eric W. Biederman
2002-10-21 22:26 Adam J. Richter

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=m1elaum3lg.fsf@frodo.biederman.org \
    --to=ebiederm@xmission.com \
    --cc=adam@yggdrasil.com \
    --cc=eblade@blackmagik.dynup.net \
    --cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox