On Tue, 07 Aug 2007, Tejun Heo wrote:Henrique de Moraes Holschuh wrote:On Tue, 07 Aug 2007, Tejun Heo wrote:Well, I'm complaining. I think the problem here is that it isn't clearMichael Sedkowski wrote:You know, this actually make a lot of sense, and one can't even complainOh... crap, so acpi wants to sync cache on shutdown. I wonder whetherHmmm... If the problem only shows up on nx6325, it might be that ACPI isDisk spins down on "Pre-shutdown prepare" and then goes up and down on
pulling unnecessary stunt. Please apply the attached patch and report
when the disk spins down and up.
"Power down".
it spins down the disk correctly. Does emergency unload count increase
after each power down? Also, please post the result of 'dmidecode'.
about firmware that pulls that off.
which one is who's responsibility. There's a Korean saying which
The BIOS *has* to do it when in DOS mode, the HD manuals are very very clear
about it. Doing it through ACPI ATA objects is at least non-broken as far
as these things go, as one knows when to do it directly ("non-ACPI mode"),
and one doesn't talk to the disk directly.
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.
want the ATA controller to be in enabled state when ACPI suspend is
invoked because the suspend method apparently wants to execute some
commands before going to sleep.
That's just broken, since it is not even using a OS-backed SATA/ATA ACPI
method to do it.
I wish ACPI spec carries a big fat sign saying "stay f*** away from
anything which isn't essential to the requested operation".
Shutting down disks *is* essential to the power off operation. ACPI would
have to mandate who is to do it, instead (ACPI table or OSI by itself).
Any chances of changing thingsNo, we can't unless we snoop ACPI method execution and detect accesses
so that we inspect/snoop all tasks sent to the device, and filter them
out, or react to them accordingly?
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(?).