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.
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.