Bug 4580 - hda: lost interrupt when resuming from S3 - Sony VGN-T1XP
hda: lost interrupt when resuming from S3 - Sony VGN-T1XP
Status: CLOSED CODE_FIX
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend
i386 Linux
: P2 normal
Assigned To: Rafael J. Wysocki
:
: 4435 (view as bug list)
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2005-05-03 09:07 UTC by Carlos
Modified: 2010-11-26 14:37 UTC (History)
6 users (show)

See Also:
Kernel Version: 2.6.11
Tree: Mainline
Regression: ---


Attachments
dmesg -s 40000 (10.70 KB, application/octet-stream)
2005-05-03 09:09 UTC, Carlos
Details
dmidecode output (6.41 KB, application/octet-stream)
2005-05-03 09:11 UTC, Carlos
Details
output of acpidmp (81.10 KB, application/octet-stream)
2005-05-03 09:13 UTC, Carlos
Details
output lspci -vv (11.13 KB, application/octet-stream)
2005-05-03 09:14 UTC, Carlos
Details
cat /proc/interrupts (354 bytes, application/octet-stream)
2005-05-03 09:15 UTC, Carlos
Details

Description Carlos 2005-05-03 09:07:49 UTC
Distribution: Gentoo
Hardware Environment: Sony Vaio VGN-T1XP
Software Environment:
Problem Description:

When resumung from S3, I get the follwing error:
Stopping tasks: ==============================================|
Back to C!
Warning: CPU frequency is 600000, cpufreq assumed 1100000 kHz.
ACPI: PCI Interrupt 0000:00:1f.1[A]: no GSI
ACPI: PCI Interrupt 0000:00:1f.5[B] -> Link [LNKB] -> GSI 9 (level, low) -> IRQ 9
PCI: Setting latency timer of device 0000:00:1f.5 to 64
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
MCE: The hardware reports a non fatal, correctable incident occurred on CPU 0.
Bank 1: f200000000000115
hda: lost interrupt
    ACPI-0299: *** Error: No installed handler for fixed event [00000002]
Restarting tasks... done
ALPS Touchpad (Glidepoint) detected
  Enabling hardware tapping
input: AlpsPS/2 ALPS TouchPad on isa0060/serio1
hda: dma_timer_expiry: dma status == 0x21
hda: DMA timeout error
hda: dma timeout error: status=0x50 { DriveReady SeekComplete }

ide: failed opcode was: unknown
hda: status error: status=0x50 { DriveReady SeekComplete }

ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE
hda: status error: status=0x50 { DriveReady SeekComplete }

ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE
hda: lost interrupt
hda: status error: status=0x50 { DriveReady SeekComplete }

ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE
hda: status error: status=0x50 { DriveReady SeekComplete }

ide: failed opcode was: unknown
hda: no DRQ after issuing MULTWRITE
ide0: reset: success

Steps to reproduce:
echo -n mem > /sys/power/state

I have updated to ACPI-patches: Subsystem revision 20050408

After a certain ammount of waiting, I can resume my work. I hope I have attached
all needed information, otherwise, just tell me.
Comment 1 Carlos 2005-05-03 09:09:05 UTC
Created attachment 5016 [details]
dmesg -s 40000
Comment 2 Carlos 2005-05-03 09:11:56 UTC
Created attachment 5017 [details]
dmidecode output
Comment 3 Carlos 2005-05-03 09:13:53 UTC
Created attachment 5018 [details]
output of acpidmp
Comment 4 Carlos 2005-05-03 09:14:32 UTC
Created attachment 5019 [details]
output lspci -vv
Comment 5 Carlos 2005-05-03 09:15:14 UTC
Created attachment 5020 [details]
cat /proc/interrupts
Comment 6 Shaohua 2005-05-08 00:38:23 UTC
*** Bug 4435 has been marked as a duplicate of this bug. ***
Comment 7 Len Brown 2005-08-17 12:29:43 UTC
same in 2.6.13?
Comment 8 Maximilian Engelhardt 2005-09-06 13:07:29 UTC
Yes, I still have this problem with 2.6.13
Comment 9 Shaohua 2005-11-08 19:56:37 UTC
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.
Comment 10 Maximilian Engelhardt 2005-11-10 06:07:06 UTC
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  
Comment 11 Carlos 2006-01-01 03:58:39 UTC
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).
Comment 12 Meinhardt 2006-03-21 03:04:22 UTC
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.
Comment 13 Len Brown 2007-08-18 15:03:29 UTC
            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.
Comment 14 Maximilian Engelhardt 2007-09-17 08:03:14 UTC
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
[...]

Comment 15 Rafael J. Wysocki 2007-09-22 03:52:15 UTC
Can you please retest with libata and this patch applied:
http://marc.info/?l=linux-acpi&m=118973889932171&w=4
Comment 16 Rafael J. Wysocki 2007-09-23 05:21:50 UTC
Alternatively, make sure that you have BLK_DEV_IDEACPI set in the .config and if not, please set it and retest.
Comment 17 Maximilian Engelhardt 2007-09-23 07:31:54 UTC
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.
Comment 18 Rafael J. Wysocki 2007-09-23 10:54:38 UTC
(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?
Comment 19 Maximilian Engelhardt 2007-09-23 15:20:22 UTC
(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.
Comment 20 Rafael J. Wysocki 2007-09-23 15:46:27 UTC
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.
Comment 21 Anonymous Emailer 2007-09-24 09:06:34 UTC
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

Comment 22 Bartlomiej Zolnierkiewicz 2007-10-08 14:36:31 UTC
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.
Comment 23 Maximilian Engelhardt 2007-10-19 09:53:25 UTC
(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.
Comment 24 ykzhao 2008-09-23 01:39:15 UTC
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.
Comment 25 Maximilian Engelhardt 2008-09-25 06:55:11 UTC
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.
Comment 26 Pádraig Brady 2010-11-26 14:37:04 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.