tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: CVS commit: src/sys/kern

On Thu, Feb 21, 2008 at 12:36:33PM +0100, Matthias Drochner wrote:
> said:
> > > Modified Files:
> > >   src/sys/kern: kern_subr.c
> > > Don't call pmf_system_shutdown() from doshutdownhooks()
> > Please, come discuss this with us on tech-kern. 
> OK, let me tell some of reasons why calling the suspend
> code in mi shutdown is wrong:
> -As said, eg. in the RB_HALT case on i386 we want the keyboard
>  to respond at the "press any key" prompt.
>  I've seen Joerg's patch from last night, which sends a
>  keyboard enable on poll, but that is wrong: If suspend()
>  was called before, one must assume that the keyboard
>  controller (and other bridges upstream the bus) are
>  suspended, thus the enable call accesses registers of a
>  suspended device. It happens to work on modern hardware
>  by some luck: The LPC/ISA bridge is part of the southbridge
>  which doesn't take part in PCI power management. (It is
>  handled by ACPI directly, which doesn't get engaged in
>  the shutdown process.) And the keyboard controller driver
>  doesn't check whether it is suspended.
> -On platforms where the firmware doesn't deal with PCI power
>  management, it might not get the hardware out of D3
>  on reboot. In case it does a hardware reset, it is fine,
>  otherwise not. mi code can't know.
> -PCI devices in extender boxes can't be reset by the BIOS,
>  so they would stay dead forever.

We had a similar issues some time ago, where disk would be spun down on
reboot or halt without powerdown. My conclusion was that drivers needs to
know what kind of suspend we're doing (suspend, reboot, halt, poweroff) to
take appropriate action (which may not always be to power off the device).
At this time, the disk issue was fixed by a hack using global variable.
But I still believe drivers needs to get more informations from PMF to
know what's going on.

Manuel Bouyer, LIP6, Universite Paris VI.  
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index