Re: Disk spin down issue on shut down/suspend to disk

[Robert Hancock]

Thomas Renninger wrote:
> On Thu, 2007-08-09 at 15:16 +0000, Pavel Machek wrote:
> > Hi!
> >
> > > > firmwarekit-discuss <firmwarekit-discuss@xxxxxxxxxxx> (added to CC list)
> > > > see: http://linuxfirmwarekit.org/
> > > >
> > > > But if I understand this problem right, this won't be easy.
> > > > The ACPI tables are just parsed with system ("iasl ...") and syntactical
> > > > errors/warnings are printed out.
> > > > I also thought about a test, interpreting the DSDT and read out values
> > > > of cpufreq tables and sanity check them. AFAIK the linuxfirmwarekit is
> > > > not designed for that atm. You need to compile in most parts of the
> > > > acpica code and parse and interpret DSDT/SSDT code yourself in the
> > > > firmwarekit core or inside a plugin, then do a walk_namespace call or
> > > > whatever to find the functions/parts you like to examine. This is a lot
> > > > work and needs a proper design (providing an interface to plugins to let
> > > > them easily check specific AML/ASL code).
> > > Furthermore, we don't really know what we're looking for.  How can you
> > > tell a given write to an ioport is issuing STANDBYNOW to an ATA disk or
> > > trying to power the machine off?  Adding to the fun, many modern ATA
> > > controller have more than one way to issue a command.  Maybe we can
> > > match accesses inside regions specified by PCI BARs....  :-(
> > Hmmm... perhaps we should do it the other way. ACPI is allowed to
> > touch the embedded controller, what else? Maybe we should warn as soon
> > as API touches non-EC I/O port?
>
> This is not working...
> ACPI can and does access all kind of other I/O ports and other
> resources.
> Hmm, are the disk accesses done by ACPI via OperationRegion/Field
> declared variables?
> I try to get a check for those clashing with native drivers (hopefully
> this approach is successful for 2.6.24, can't say for sure yet), I
> wonder whether this one would give a warning like "Libata driver is
> using the same SystemIO/SystemMem resources than ACPI OperationRegion
> declaration XY".
> This would not solve the problem, but at least show the need of such a
> test. Such ACPI vs native driver interference problems are very hard
> nuts (in identifying and solving).
>
> Can someone post an ASL code snippet how ACPI actually access the disk
> and in which parts/functions, pls.

Again, it's not believed that this is being done via AML, but via a BIOS 
SMM trap on the ACPI sleep state hardware IO port. We have no real 
ability to find out what the BIOS is doing or prevent it in this case.

--
Robert Hancock      Saskatoon, SK, Canada
To email, remove "nospam" from hancockr@xxxxxxxxxxxxx
Home Page: http://www.roberthancock.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/