lkml.org 
[lkml]   [1998]   [Nov]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:45    [from the cache]
©2003-2011 Jasper Spaans