> > > 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/