[lkml]   [1998]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: APM "SuspendToDisk" implementation problem
    On Tue, 24 Nov 1998, Alan Cox wrote:

    > > > Well actually the APM bios needs fixing
    > >
    > > I don't think this is the solution. What if you have this new, fancy disk
    > > the bios knows nothing about ? Scsi controller ? Firewire ?
    > > Of course the bios has to know how to save the memory, but it doesn't have
    > > to be the only disk.
    > Tough 8) This is why the APM is a stupid specification.

    I'm not sure what in particular you think is stupid about it, because
    in this context, I can't think of an obvious way to do better without
    using something like <groan> ACPI, where devices are self-describing.

    > > > The bios is supposed to save the state of stuff. I understood
    > > > the problem as being the disk reverted back to dumb mode, in
    > > > which case presumably you can at least slowly run hdparm ..
    > > >
    > > You can't. The kernel cries about IRQ's being lost (judging from the
    > > reports of other people)..
    > So long as it recovers after the
    > ide0: reset
    > all is fine

    I think the point is sometimes the IDE driver can't properly recover
    in this situation. There are really two ways to properly fix suspend:

    1. Device drivers can be "bullet proofed" to the point that they can
    recover automatically from a complete loss of device state.

    2. Drivers can be made APM-aware, so that they directly handle APM
    suspend and resume notifications.

    I think both are desirable. Strange things happen and drivers should
    be fault tolerant. This doesn't have to be horribly expensive... it
    might just mean sanity checking status values in a few key places, and
    having the ability to do a from-scratch initialization of a device if
    all else fails. And even if drivers can blindly recover from a
    suspend, eventually we won't be satisfied with spewing messages about
    unresponsive devices whenever a system is resumed, and we'll want to
    distinguish this situation from a genuine hardware problem.

    -- Dave Hinds

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:45    [W:0.021 / U:11.204 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site