Re: PATCH: Shutdown IDE before powering off.

Re: PATCH: Shutdown IDE before powering off.

[Karol Kozimor]

Thus wrote Bartlomiej Zolnierkiewicz:
> 
> On Thursday 22 of January 2004 17:02, Jeff Garzik wrote:
> > I'm either shock or very very worried that the reboot notifier that
> > flushes IDE in 2.4.x, ide_notifier, is nowhere to be seen in 2.6.x :(
> > That seems like the real problem -- the code _used_ to be there.
> 
> Yep, it should be re-added.  I wonder when/why it was removed?

Hi,
What's the current status of this issue?
Best regards,

-- 
Karol 'sziwan' Kozimor
sziwan@hell.org.pl

Broken PM semantics (WAS: PATCH: Shutdown IDE before powering off).

[Benjamin Herrenschmidt]

On Fri, 2004-03-12 at 08:46, Karol Kozimor wrote:
> Thus wrote Bartlomiej Zolnierkiewicz:
> > 
> > On Thursday 22 of January 2004 17:02, Jeff Garzik wrote:
> > > I'm either shock or very very worried that the reboot notifier that
> > > flushes IDE in 2.4.x, ide_notifier, is nowhere to be seen in 2.6.x :(
> > > That seems like the real problem -- the code _used_ to be there.
> > 
> > Yep, it should be re-added.  I wonder when/why it was removed?

Ideally, it should use the same mecanism as the PM requests...

In fact, the shutdown is just a special case of PM request. I think
ultimately, we should drop the various "shutdown()" functions in the
drivers in favor of a "state" selector for PM. That goes along with
the current problem of "state" in PM beeing completely bogus. The
constants defined by linux/pm.h are in no way related to what
the various drivers have come to expect.

enum {
        PM_SUSPEND_ON,
        PM_SUSPEND_STANDBY,
        PM_SUSPEND_MEM,
        PM_SUSPEND_DISK,
        PM_SUSPEND_MAX,
};
                                                                                                                   
Which basically gives is MEM=2 and DISK=3, while drivers usually
expect MEM=3 and DISK=4 while nobody really cares about 2 except
some specific stuffs in the arch code (or radeonfb on pmacs...)

We should get rid of this assumption that we are passing a D-type
anyway. I suggest we define once for all that what we are passing
down the driver is really the overall system state we are getting
to, that is MEM,DISK,KEXEC,SHUTDOWN, eventually STANDBY if we
ever do something like that (useful for handhelds that have a
special idle state and really don't care about scheduling whne
nothing happens for a while).

Ben.

Re: Broken PM semantics (WAS: PATCH: Shutdown IDE before powering off).

[Pavel Machek]

Hi!

> > Thus wrote Bartlomiej Zolnierkiewicz:
> > > 
> > > On Thursday 22 of January 2004 17:02, Jeff Garzik wrote:
> > > > I'm either shock or very very worried that the reboot notifier that
> > > > flushes IDE in 2.4.x, ide_notifier, is nowhere to be seen in 2.6.x :(
> > > > That seems like the real problem -- the code _used_ to be there.
> > > 
> > > Yep, it should be re-added.  I wonder when/why it was removed?
> 
> Ideally, it should use the same mecanism as the PM requests...
> 
> In fact, the shutdown is just a special case of PM request. I think
> ultimately, we should drop the various "shutdown()" functions in the
> drivers in favor of a "state" selector for PM. That goes along with
> the current problem of "state" in PM beeing completely bogus. The
> constants defined by linux/pm.h are in no way related to what
> the various drivers have come to expect.
> 
> enum {
>         PM_SUSPEND_ON,
>         PM_SUSPEND_STANDBY,
>         PM_SUSPEND_MEM,
>         PM_SUSPEND_DISK,
>         PM_SUSPEND_MAX,
> };
>                                                                                                                    
> Which basically gives is MEM=2 and DISK=3, while drivers usually
> expect MEM=3 and DISK=4 while nobody really cares about 2 except
> some specific stuffs in the arch code (or radeonfb on pmacs...)
> 
> We should get rid of this assumption that we are passing a D-type
> anyway. I suggest we define once for all that what we are passing
> down the driver is really the overall system state we are getting
> to, that is MEM,DISK,KEXEC,SHUTDOWN, eventually STANDBY if we
> ever do something like that (useful for handhelds that have a
> special idle state and really don't care about scheduling whne
> nothing happens for a while).

Agreed. Or at least document that it takes D states
and BUG-ON on invalid values...
				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms