Bug 4580

Created attachment 5016 [details]
dmesg -s 40000

Created attachment 5017 [details]
dmidecode output

Created attachment 5018 [details]
output of acpidmp

Created attachment 5019 [details]
output lspci -vv

Created attachment 5020 [details]
cat /proc/interrupts

*** Bug 4435 has been marked as a duplicate of this bug. ***

same in 2.6.13?

Yes, I still have this problem with 2.6.13

Could you please try the patch at bug 2039 and report it back? Let's see if 
the ide failure is caused by lack of invoking ACPI metthods.

The patch doesn't change anything on my system (beside some more debug output), 
I'm still getting the same error message: 
http://home.daemonizer.de/kernel/2.6.14_ide_patch.png  

The problem still exists on 2.6.14 WITH the patch from bug 2039. 

It even got worse inbetween the kernel from my original bug post and the current
stable kernel. Now, with or without the patch, the system hangs when I try to
access the disk after an resume (e.g. I can change the console or type, but as
soon as any disk access happens, nothing happens. I can see a hda: lost
interrupt all 30 seconds on messages).

Got the same Problem on a Sony Vaio VGN-B1VP
No matter which Distribution I use...
I tested the 2.6.12 and 2.6.15 Vanilla Kernel.

            Device (IDEC)
            {
                Name (_ADR, 0x001F0001)
...

                Device (PRID)
                {
                    Name (_ADR, 0x00)
                    Method (_GTM, 0, NotSerialized)
...
                    Method (_STM, 3, NotSerialized)
                    Device (P_D0)
                    {

This system uses the ACPI extensions to ATA
which have been absent from Linux.

Please try 2.6.23.git with the latest ide-acpi support.

I tried the old ide drivers as well as the libata drivers with 2.6.23-rc6-git7 on my laptop. With both resuming from S3 did not work.

With libata I get:

sd 0:0:0:0: [sda] Starting disk
ata2.00: revalidation failed (errno=-2)
ata2: failed to recover some devices, retrying in 5 secs
ata1.00: configured for UDMA/100
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data0
         res 51/04:01:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
ata1.00: configured for UDMA/100
ata1: EH complete
ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
ata1.00: cmd 40/00:01:00:00:00/00:00:00:00:00/e0 tag 0 cdb 0x0 data0
         res 51/04:01:00:00:00/00:00:00:00:00/e0 Emask 0x1 (device error)
[...]

and using the ide drive I get:

hda: dma_intr: status0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda: dma_intr: status0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda: dma_intr: status0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda: dma_intr: status0x51 { DriveReady SeekComplete Error }
hda: dma_intr: error=0x04 { DriveStatusError }
ide: failed opcode was: unknown
hda: DMA disabled
ide0: reset: success
hda: task_out_intr: status0x51 { DriveReady SeekComplete Error }
hda: task_out_intr: { DriveStatusError }
ide: failed opcode was: unknown
[...]

Can you please retest with libata and this patch applied:
http://marc.info/?l=linux-acpi&m=118973889932171&w=4

Alternatively, make sure that you have BLK_DEV_IDEACPI set in the .config and if not, please set it and retest.

I had the time to do some more test and here are the results:

resuming does work with IDE (BLK_DEV_IDEACPI enabled, didn't test without it) as well as with ATA (with and without the patch from comment #15) if I have my HDD password disabled.

If I enable my HDD password the system still does resume and using 's2ram -f -s' I even get the video back, but in all cases HDD access doesn't work anymore. Using IDE and ATA (without patch) I get the errors from my comment #14. When using ATA with the patch from comment #15 I think the dmesg output is a bit different, but I still can't access the HDD.

All test have been done using kernel-2.6.23-rc6-git7 and most of the unimportant/problematic stuff (like usb or framebuffer) had been disabled.

(In reply to comment #17)
> I had the time to do some more test and here are the results:
> 
> resuming does work with IDE (BLK_DEV_IDEACPI enabled, didn't test without it)
> as well as with ATA (with and without the patch from comment #15) if I have
> my
> HDD password disabled.
> 
> If I enable my HDD password the system still does resume and using 's2ram -f
> -s' I even get the video back, but in all cases HDD access doesn't work
> anymore.

What is the HDD password?  How do you enable it?

(In reply to comment #18)
> What is the HDD password?  How do you enable it?

AFAIK it is part of the ATA specification. It's a password that protects the data on the harddrive from unauthorized access. When powering the drive you first have to send the password to the disk to unlock it. This is usually done by the BIOS.

Hdparm also has support for playing with it, but I never tried it. There it's called "ATA Security Feature Set"

When I turn my laptop on the BIOS asks me for the HDD password. After I enter it correctly the HDD is unlocked and the BIOS continues with the boot sequence.

I did set/clear the password in the BIOS of my laptop.

This probably is the Host Protected Area (HPA) and we had problems with that in the past.

Unfortunately, I'm not an ATA expert, so we'd have to ask someone for help.

Reply-To: charles.marslett@intel.com

acpi-bugzilla-bounces@lists.sourceforge.net <> wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=4580
> 
> ------- Comment #20 from rjwysocki@sisk.pl  2007-09-23 15:46 -------
> This probably is the Host Protected Area (HPA) and we had
> problems with that in
> the past.
> 
> Unfortunately, I'm not an ATA expert, so we'd have to ask
> someone for help.
> 
> --
> Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
> 
> ---------------------------------------------------------------
> ----------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> acpi-bugzilla mailing list
> acpi-bugzilla@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla

I am not an ATA expert either, but this sounds like the problem I
investigated at a previous employer.  When resuming from S3, the hard
drive password has to be resubmitted to the drive since it was powered
down during the S3 "shutdown".

In order to avoid the time it takes to initialize the ATA subsystem, if
a password was not set, we just skipped initializing the subsystem.  But
we had to initialize it and submit the password to each drive if one was
set.  This sounds like what is happening (or not happening) in this
report.

Later we found that we had to initialize the ATA subsystem and "freeze"
the hard drive password to prevent the OS or 3rd party tools from
setting up the hard drive password if the password was not set (this is
because we hashed the password to prevent the drive from being moved to
another system and hacked if the user had a reasonably easy password
("MyInspiron", for example; and the other tools do not know the hashing
algorithm).

--Charles

CONFIG_BLK_DEV_IDEACPI=y is not enough since IDE ACPI _GTF support is disabled
by default.  To enable it "ide=acpigtf" kernel parameter should be used.

Sometimes it may be also worth to try enabling usage of IDE ACPI methods on
boot ("ide=acpionboot" kernel parameter) which is also disabled by default.

(In reply to comment #22)
> CONFIG_BLK_DEV_IDEACPI=y is not enough since IDE ACPI _GTF support is
> disabled
> by default.  To enable it "ide=acpigtf" kernel parameter should be used.
When I use ide=acpigtf my system freezes when resuming. I tried with the password enabled and disabled and it's always the same.

> Sometimes it may be also worth to try enabling usage of IDE ACPI methods on
> boot ("ide=acpionboot" kernel parameter) which is also disabled by default.
ide=acpionboot doesn't seem to change anything (compared to using no option). When I have the password disbaled resuming does work, when it's enabled the system resumes but the hdd isn't accessable anymore.

Hi, Maximilian
    Will you please try the latest kernel(2.6.27-rc6/rc7) and see whether the problem still exists?
    If exists, please do the following test and then check whether the problem still exists.
    a. echo core > /sys/power/pm_test
    b. echo mem > /sys/power/state/
    
    Thanks.

I tried again with 2.6.27-rc7 and suspending to ram seems to work perfectly fine now. I couldn't find any problems with it.

So for me this bug is fixed.

Just tried this again with 2.6.35.6-48.fc14.i686
Previously it would resume fine, but fail on accessing disk
Now it just completely hangs, caps lock doesn't work or anything
If I do this, it suspends and auto resumes fine:
  echo core > /sys/power/pm_test
Once "none" is in there, then upon resuming after the full suspend,
the system will hang.