Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 09:51 -0300, Henrique de Moraes Holschuh wrote: > On Tue, 07 Aug 2007, Tejun Heo wrote: > > Henrique de Moraes Holschuh wrote: > > > On Tue, 07 Aug 2007, Tejun Heo wrote: > > >> Michael Sedkowski wrote: ---snip--- > > > Any chances of changing things > > > so that we inspect/snoop all tasks sent to the device, and filter them > > > out, or react to them accordingly? > > > > No, we can't unless we snoop ACPI method execution and detect accesses > > to IO ports or iomem regions. It's not going through any driver. This > > is a gross mess. > > I don't mean fixing the stuff clowns like Toshiba did. The correct fix for > that is to blacklist the hell out of that crap and patch their DSDT into > something remotely sane. > > I do mean snooping the ACPI methods that *return* a taskset to send to the > driver, and we send that taskset ourselves in libata and libpata(?). I haven't read the whole thread in every detail, but this sounds like a very intrusive, overdosed workaround. Are the DSDT/SSDTs already lying around somewhere (collecting them in a bug assigned to ACPI component should be a good idea)? Could someone give me a pointer where this happens (best in code and DSDT). Thanks, Thomas - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 22:32 +0900, Tejun Heo wrote:
> Henrique de Moraes Holschuh wrote:
> > On Tue, 07 Aug 2007, Tejun Heo wrote:
> >> Henrique de Moraes Holschuh wrote:
> approximately translates into "if you have too many boatmen on a ship,
> it goes to mountain". We also have a bunch of Toshiba laptops which
> >>> Yeah, that's a problem. But we can avoid it if we start snooping what
> >>> ACPI
> >>> is asking us to deliver to the disks, which IMO is an extremely good idea
> >>> anyway.
> >> If it were done that way (by asking OS driver to deliver commands TFs),
> >> I wouldn't have any problem at all. The spin down command is issued
> >> from deep down in the acpi power off method - entering S5 directly
> >> issues ATA commands bypassing the whole OS except for the ACPI
> >> interpreter. It's just like the toshiba suspend crap and there's no
> >> standard way to tell whether the acpi power off method is gonna do it or
> >> not. We'll just have to blacklist it.
> >
> > Urk. I see.
> >
> > I'd also suggest adding a FAIL to the Linux firmware toolkit to any DSDT
> > doing this. Who should we prod to add that check?
>
> Dunno how the firmware toolkit works but this one can be pretty
> difficult to test (if it were easy, we could test it in libata) as it
> involves entering S5. If it's possible, I'm all for it. Also, it would
> be nice if we can test the same thing for S3 and S4.
>
> Thomas, who should we ask things about the Linux firmware toolkit? Thanks.
firmwarekit-discuss <[EMAIL PROTECTED]> (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).
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Tue, 2007-08-07 at 15:41 +0900, Tejun Heo wrote: > Robert Hancock wrote: > > Tejun Heo wrote: > >> Michael Sedkowski wrote: > Hmmm... If the problem only shows up on nx6325, it might be that > ACPI is > pulling unnecessary stunt. Please apply the attached patch and report > when the disk spins down and up. > >>> Disk spins down on "Pre-shutdown prepare" and then goes up and down on > >>> "Power down". > >> > >> Oh... crap, so acpi wants to sync cache on shutdown. I wonder whether > >> it spins down the disk correctly. Does emergency unload count increase > >> after each power down? Also, please post the result of 'dmidecode'. > > > > I know that my Compaq X1000-series laptop does do some kind of ACPI > > games with the disk on ACPI power off (I assume it is putting the disk > > in standby before power-off at least). It also does this if you boot > > into DOS, GRUB, etc. and then hit the power button. Could be if the disk > > is dumb enough to spin up for sync cache and standby when there is > > nothing to flush, and the kernel does its own standby, this could cause > > an extra spinup/down.. > > Yeah, that seems to be what's going on. I don't think we have any other > choice than blacklisting those notebooks. This is a mess. How does the > other OS cope with this? > > I'm thinking about using DMI vendor/product match to detect the affected > systems but I think it would be better to match the ACPI implementation > directly. Is there a way to match specific ACPI implementation? I opened a new bug to collect dmi and acpidump outputs: http://bugzilla.kernel.org/show_bug.cgi?id=8855 Thought this is the easiest way to get this all a bit together. Would be great if you tell all affected people and let them attach dmidecode and acpidump output there... Thanks, Thomas - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Disk spin down issue on shut down/suspend to disk
On Thu, 2007-08-09 at 15:16 +, Pavel Machek wrote:
> Hi!
>
> > > firmwarekit-discuss <[EMAIL PROTECTED]> (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.
Thanks,
Thomas
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
