Bug 11255
|
Description
Denys Rogovchenko
2008-08-05 23:57:29 UTC
lspci -vv... 00:00.0 Host bridge: Intel Corporation Mobile PM965/GM965/GL960 Memory Controller Hub (rev 03) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- Latency: 0 Capabilities: <access denied> 00:01.0 PCI bridge: Intel Corporation Mobile PM965/GM965/GL960 PCI Express Root Port (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=08, subordinate=08, sec-latency=0 I/O behind bridge: 0000c000-0000cfff Memory behind bridge: f8a00000-feafffff Prefetchable memory behind bridge: 00000000d0000000-00000000dfffffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA+ MAbort- >Reset- FastB2B- Capabilities: <access denied> 00:1a.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 03) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 4: I/O ports at d800 [size=32] 00:1a.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 03) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 21 Region 4: I/O ports at d480 [size=32] 00:1a.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 03) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin C routed to IRQ 18 Region 0: Memory at febfec00 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> 00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 03) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 21 Region 0: Memory at febf8000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> 00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 03) (prog-if 00 [Normal decode]) Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=02, subordinate=02, sec-latency=0 Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: <access denied> 00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=03, subordinate=03, sec-latency=0 I/O behind bridge: 00009000-00009fff Memory behind bridge: f7f00000-f7ffffff Prefetchable memory behind bridge: 00000000c4000000-00000000c40fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: <access denied> 00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=04, subordinate=05, sec-latency=0 I/O behind bridge: 0000a000-0000afff Memory behind bridge: f8000000-f87fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: <access denied> 00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 03) (prog-if 00 [Normal decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=06, subordinate=06, sec-latency=0 Memory behind bridge: f8800000-f88fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: <access denied> 00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 03) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR- Latency: 0, Cache Line Size: 32 bytes Bus: primary=00, secondary=07, subordinate=07, sec-latency=0 I/O behind bridge: 0000b000-0000bfff Memory behind bridge: f8900000-f89fffff Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR- BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: <access denied> 00:1d.0 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 03) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 4: I/O ports at e000 [size=32] 00:1d.1 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 03) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 19 Region 4: I/O ports at dc00 [size=32] 00:1d.2 USB Controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 03) (prog-if 00 [UHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin C routed to IRQ 18 Region 4: I/O ports at d880 [size=32] 00:1d.7 USB Controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 03) (prog-if 20 [EHCI]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 23 Region 0: Memory at febff000 (32-bit, non-prefetchable) [size=1K] Capabilities: <access denied> 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3) (prog-if 01 [Subtractive decode]) Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Bus: primary=00, secondary=01, subordinate=01, sec-latency=32 Memory behind bridge: f7e00000-f7efffff Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR+ BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B- Capabilities: <access denied> 00:1f.0 ISA bridge: Intel Corporation 82801HEM (ICH8M) LPC Interface Controller (rev 03) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Capabilities: <access denied> 00:1f.1 IDE interface: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) IDE Controller (rev 03) (prog-if 8a [Master SecP PriP]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 19 Region 0: I/O ports at 01f0 [size=8] Region 1: I/O ports at 03f4 [size=1] Region 2: I/O ports at 0170 [size=8] Region 3: I/O ports at 0374 [size=1] Region 4: I/O ports at ffa0 [size=16] 00:1f.2 SATA controller: Intel Corporation 82801HBM/HEM (ICH8M/ICH8M-E) SATA AHCI Controller (rev 03) (prog-if 01 [AHCI 1.0]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin B routed to IRQ 312 Region 0: I/O ports at ec00 [size=8] Region 1: I/O ports at e880 [size=4] Region 2: I/O ports at e800 [size=8] Region 3: I/O ports at e480 [size=4] Region 4: I/O ports at e400 [size=32] Region 5: Memory at febff800 (32-bit, non-prefetchable) [size=2K] Capabilities: <access denied> 00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 03) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin C routed to IRQ 15 Region 0: Memory at febff400 (32-bit, non-prefetchable) [size=256] Region 4: I/O ports at 0400 [size=32] 01:04.0 FireWire (IEEE 1394): O2 Micro, Inc. Firewire (IEEE 1394) (rev 02) (prog-if 10 [OHCI]) Subsystem: O2 Micro, Inc. Firewire (IEEE 1394) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 64, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 17 Region 0: Memory at f7eff000 (32-bit, non-prefetchable) [size=4K] Region 1: Memory at f7efe800 (32-bit, non-prefetchable) [size=2K] Capabilities: <access denied> 01:04.2 SD Host controller: O2 Micro, Inc. Integrated MMC/SD Controller (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin A routed to IRQ 17 Region 0: Memory at f7efe400 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> 01:04.3 Mass storage controller: O2 Micro, Inc. Integrated MS/xD Controller (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- <TAbort- <MAbort- >SERR- <PERR- Interrupt: pin A routed to IRQ 11 Region 0: Memory at f7efd000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> 03:00.0 Memory controller: Intel Corporation Turbo Memory Controller (rev 01) Subsystem: Intel Corporation Turbo Memory Controller Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at f7fffc00 (32-bit, non-prefetchable) [size=1K] Region 2: I/O ports at 9c00 [size=128] [virtual] Expansion ROM at c4000000 [disabled] [size=64K] Capabilities: <access denied> 06:00.0 Network controller: Intel Corporation PRO/Wireless 4965 AG or AGN Network Connection (rev 61) Subsystem: Intel Corporation Unknown device 1101 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 311 Region 0: Memory at f88fe000 (64-bit, non-prefetchable) [size=8K] Capabilities: <access denied> 07:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR+ <PERR- Latency: 0, Cache Line Size: 32 bytes Interrupt: pin A routed to IRQ 313 Region 0: I/O ports at b800 [size=256] Region 2: Memory at f89ff000 (64-bit, non-prefetchable) [size=4K] Expansion ROM at f89c0000 [disabled] [size=128K] Capabilities: <access denied> 08:00.0 VGA compatible controller: nVidia Corporation GeForce 8600M GS (rev a1) (prog-if 00 [VGA controller]) Subsystem: Micro-Star International Co., Ltd. Unknown device 4327 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- Latency: 0 Interrupt: pin A routed to IRQ 16 Region 0: Memory at fd000000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at d0000000 (64-bit, prefetchable) [size=256M] Region 3: Memory at fa000000 (64-bit, non-prefetchable) [size=32M] Region 5: I/O ports at cc00 [size=128] [virtual] Expansion ROM at feae0000 [disabled] [size=128K] Capabilities: <access denied> Please attach the acpidump as an attachment here. you can use the latest pmtools at http://www.lesswatts.org/patches/linux_acpi/ Please attach the full dmesg output as well. Created attachment 17116 [details]
dmesg
dmesg
Created attachment 17117 [details]
acpi dump
acpi dump
It seems that in my laptop LG company put MSI motherboard... but I don't know is it help or not.... Please make sure CONFIG_ACPI_DEBUG is set in your kernel config and boot with "acpi.debug_layer=0x44 acpi.debug_level=0x8800001f" Well, should I attach after that dmesg and acpidump again? Please just attach the dmesg output. :) Created attachment 17186 [details]
new dmesg :)
dmesg out with acpi.debug_layer=0x44 acpi.debug_level=0x8800001f kernel parameters and kernel was recompiled with CONFIG_ACPI_DEBUG=y
Created attachment 17209 [details]
try the debug patch
Will you please try the debug patch and attach the output of dmesg?
Thanks.
Hi, Denys
Will you please confirm whether the system can work on the kernel before 2.6.25?
If it can't work, it is not a regression.
thanks.
So, if it is not a regression, is it really that you cannot help? Created attachment 17227 [details]
dmesg with patch and debug start kernel parameters
Please don't add the boot option of "acpi.debug_layer=0x44 acpi.debug_level=0x8800001f" and attach the output of dmesg. Of course the patch in comment #10 is still needed. Will you please confirm whether the system is affected by the following error message? > 0.161641] ACPI Error (evregion-0316): No handler for Region [EC__] (ffff81013fc153a8) [EmbeddedControl] [20080321] >[ 0.161658] ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321] >[ 0.161672] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff81013fc17a00), AE_NOT_EXIST >[ 0.161716] ACPI Error (uteval-0233): Method execution failed Thanks. Hi, Denys
As you said that suspend/hibernation can't work on your laptop in comment #1, Do you mean that the system can enter the suspend state? Right?
Will you please confirm whether suspend/hibernation can work on windows?
Thanks.
Hi, Denys
Will you please confirm whether the system can be shutdown correctly?
Thanks.
1. In windows hibernate&sleep mode work correctly. I bought my laptop (unfortunately) with preinstalled windows Vista. 2. Yes my laptop can shutdown. 3. when I try to use hibernation or sleep - seems like all works, but when I try to push any button for awake my laptop is startting and suddonly restart and start again and after that I'm seeing just black screen. I have investigated have whether problem another users who have another laptops or PC, and all people who has problem with ACPI - have the similary behavior, I mean restarting after awake... Created attachment 17238 [details]
dmesg without any start parameters
Hi, Denys
Thanks for so quick response.
From the acpidump it seems that the warning message is related with the BIOS.
> Name (MYEC, One)
>Method (_REG, 2, NotSerialized)
{
If (LEqual (Arg0, 0x03))
{
Store (Arg1, MYEC)
}
Before the _REG object for EC is evaluated, the flag of MYEC is already 1, which is used to determine whether EC space handler is installed.
Will you please try to add the boot option of "initcall_debug" and attach the output of dmesg? (Of course the patch in comment #10 is still needed).
Thanks.
Created attachment 17351 [details]
new one
debug_initcall
I have tried 2.6.27-rc4 kernel - the same situation... sleep and hibernate didn't work.... Created attachment 17432 [details] try the debug patch Hi, Denys Thanks for the test and confirm. For your laptop there are two issues. a. The warning message during initialization b. sleep&hibernate can't work The issue a is related with BIOS. > Name (MYEC, One) // should be initialized as zero instead of one >Method (_REG, 2, NotSerialized) { If (LEqual (Arg0, 0x03)) { Store (Arg1, MYEC) } And after the commit is merged, OS will print the warning message. >commit 7752d5cfe3d11ca0bb9c673ec38bd78ba6578f8e > Author: Robert Hancock <hancockr@shaw.ca> > Date: Fri Feb 15 01:27:20 2008 -0800 >x86: validate against acpi motherboard resources Of course the above warning message is harmless. Will you please try the debug patch and confirm whether the issue a still exists? Thanks. As it is not a regression, clear the flag of regression. Created attachment 17440 [details]
kernel with first and second patches
sleep & hibernate don't still work...
Hi, Denys
Thanks for the test. From the log in comment #24 the warning message disappears. But the sleep&hibernate still can't work.
Will you please do the following test about S3?
a. boot the system with the option of "acpi_sleep=s3_beep"
b. after the system is booted, please kill the process which uses the /proc/acpi/event.( Use the command of "lsof /proc/acpi/event" to get which process is using the /proc/acpi/event)
c. echo mem > /sys/power/state
d. wait for about one minute and press the power button. Please confirm whether you can hear the beep voice and the system can be resumed.
Thanks.
There isn't any beep..it doesn't work :(. I have the same situation as usual, after echo mem > /sys/power/state in 3 sec my laptop switch off and power led started blinking, like pure sleep mode, but after pushing power button my laptop switch on, and suddenly switch off, after that switch on again with black screen. any buttons didn't work. For restarting I should unplug power cord and remove accumulator. Created attachment 17472 [details] try the custom DSDT Will you please try the custom DSDT and see whether the sleep&hibernate can work on your laptop? How to use the custom DSDT can be found on http://www.lesswatts.org/projects/acpi/faq.php thanks. Created attachment 17478 [details]
dmesg after dsdt replacing
I have the same result as with native dsdt table...
For me it's very strange... I've read a lot of conferences dedicated to this problem and a lot of victims wrote that i windows sleep and hibernate work correctly. If windows acpi driver can operate fluently with dsdt table which has been embedded to bios, why linux acpi part of kernel cannot work normally? Is it so hard put to command queue or something like that, commands like windows put? It's just question :) I really want that linux will be on desktops entire of the world. Created attachment 17516 [details] try the debug patch Hi, Denys What you said is right. Linux can't work well on some system but windows can work well. To make Linux compatible with windows is the target that we are seeking. But maybe it will take more time and efforts to realize it. Will you please try the debug patch and do the test required in comment #25?(The patch in comment #22 is still needed). Please attach the output of dmesg. thanks. Created attachment 17537 [details]
dmesg
Created attachment 17540 [details]
hibernate works!!!
I have tried 2.6.27-rc5 kernel with first path and have changed start parameter resume=/dev/sda7. After that I try hibernate and it works!! I really dont know about wait mode, I want to try it. So dmesg log which I presented here has been created after awake from hibernate mode.
So, wait mode still doesn't work... Hi, Denys
Will you please confirm whether hibernation can work well on the 2.6.27-rc5 kernel if the patch in commet#30 is not applied?
Of course the boot parameter of "resume=/dev/sda7" is still needed.
Thanks.
Well, I tried hibernate without patch in comment#30, but with first patch and "resume=/dev/sda7" start prameter... Hi, Denys
Will you please confirm whether you can hear the beep voice in the course of suspend/resume if the patch in comment #30 is applied and the boot option of "acpi_sleep=s3_beep" is added?
thanks.
Hi, Denys The patch in comment #30 is out of date. Will you please try the patch http://bugzilla.kernel.org/show_bug.cgi?id=11368#C53 and confirm whether the beep voice can be heard in course of suspend/resume? (Please add the boot option of "acpi_sleep=s3_beep"). Thanks. Hello! Sorry for delay, I was in vocation :) So, I've applied patches from comment #37 and comment #22 against new 2.6.27-rc6 kernel, compiled and run with this line in menu.lst: kernel /boot/vmlinuz-2.6.27-rc6-x64 root=/dev/sda5 ro vga=0x0369 acpi_sleep=s3_beep resume=/dev/sda7 After that I tried to switch to wait mode, and the same result as in past - reboot after power on and there isn't any beep. Hibernation works normally as in previous attemption. But there is not any beep as well. Hello ykzhao I just want to know is this problem still under your coverage or not... denys, please try the patch at http://marc.info/?l=linux-acpi&m=122307130419749&w=2 and see if it helps. :( still doesn't work..
Is there any posibility to add some check code here:
static int acpi_suspend_enter(suspend_state_t pm_state)
{
acpi_status status = AE_OK;
unsigned long flags = 0;
u32 acpi_state = acpi_target_sleep_state;
ACPI_FLUSH_CPU_CACHE();
/* Do arch specific saving of state. */
if (acpi_state == ACPI_STATE_S3) {
int error = acpi_save_state_mem();
if (error)
return error;
}
local_irq_save(flags);
acpi_enable_wakeup_device(acpi_state);
switch (acpi_state) {
case ACPI_STATE_S1:
barrier();
status = acpi_enter_sleep_state(acpi_state);
break;
case ACPI_STATE_S3:
do_suspend_lowlevel();
break;
}
/* If ACPI is not enabled by the BIOS, we need to enable it here. */
acpi_enable();
/* Reprogram control registers and execute _BFS */
acpi_leave_sleep_state_prep(acpi_state);
/* ACPI 3.0 specs (P62) says that it's the responsibility
* of the OSPM to clear the status bit [ implying that the
* POWER_BUTTON event should not reach userspace ]
*/
if (ACPI_SUCCESS(status) && (acpi_state == ACPI_STATE_S3))
acpi_clear_event(ACPI_EVENT_POWER_BUTTON);
/*
* Disable and clear GPE status before interrupt is enabled. Some GPEs
* (like wakeup GPE) haven't handler, this can avoid such GPE misfire.
* acpi_leave_sleep_state will reenable specific GPEs later
*/
acpi_hw_disable_all_gpes();
local_irq_restore(flags);
printk(KERN_DEBUG "Back to C!\n");
/* restore processor state */
if (acpi_state == ACPI_STATE_S3)
acpi_restore_state_mem();
return ACPI_SUCCESS(status) ? 0 : -EFAULT;
}
For example try to beep, or show some message? And another thought.. can it be result of that my hardware awake in wrong mode or something like that? I think we should go in debug way. I ready to test any conditions.
Hi, Denys
thanks for the confirm. Unfortunately there is no beep on your box in the course of resume. It will be very good to add some debug method.
Will you please do the following two tests on your box?
1. Verify whether the resume is related with the driver
a. echo core > /sys/power/pm_test ( If there is no /sys/power/pm_test file, please enable "CONFIG_PM_DEBUG" in kernel configuration)
b. echo mem > /sys/power/state
Please wait for some time to confirm whether the system is resumed.(Unnecessary to press power button).
2. Use the PM_trace
a. enable CONFIG_PM_DEBUG and CONFIG_PM_TRACE in kernel configuration
b. echo 1 > /sys/power/pm_trace
c. echo mem > /sys/power/state
d. press the power button to check whether the system is resumed. If not, please reboot by holding the power button down, and look at the dmesg output for things like the following: (It will be great if you can attach the output of dmesg after reboot)
Magic number: 4:156:725
hash matches drivers/base/power/resume.c:28
hash matches device 0000:01:00.0
Thanks.
Created attachment 18315 [details]
dmesg for test 1.
Test number 1.
I've compiled kernel with - CONFIG_PM_DEBUG and CONFIG_PM_TRACE flags, then typed - echo 1 > /sys/power/pm_trace, then typed echo mem > /sys/power/state - I had black screen with blinked cursor during 3-5 sec, and after that my normal desctop...
Test number 2 - the same situation as in suspend mode... I have to unplug/plug accumulator and after that normal cold start... shipped in linux-2.6.28-rc1: commit 455c8793d2c49eaecad038c8de83dade9fc3759f Author: Zhao Yakui <yakui.zhao@intel.com> Date: Mon Oct 6 10:31:36 2008 +0800 ACPI: Enable EC device immediately after ACPI full initialization Hi, Denys
Does there exist the following message in the dmesg out when doing the test as mentioned in comment #45?
>Magic number: 4:156:725
>hash matches drivers/base/power/resume.c:28
>hash matches device 0000:01:00.0
Will you please try the latest kernel(2.6.28-rc2) and see whether the system can be resumed from S3?
Thanks.
Ie tried 2.6.28.rc5 - same result, doesn´t work Created attachment 18926 [details]
try the debug patch in which the waking vector is set after the _PTS object
Will you please try the debug patch on 2.6.28-rc5 and see whether the problem still exists?
In the debug patch the waking vector is set after evaluating the _PTS object.
At the same time the _PTS object is evaluated before writing the SLP_TYPE to PM1A_CTRL register.
Thanks.
patch (id=18926) doesn´t help me.. Thanks for so quick response. Now I have no idea why the suspend/resume can't work on this box. And the problem summary will be changed to "suspend/resume can't work". Thanks. Created attachment 19117 [details]
use the attached tool to read I/O port
Hi
Will you please do the following test on your box?
a. boot the system with ACPI disable(add the option of "acpi=off")
b. lspci -vxxx >lspci_acpi_off ; and ./ior --addr 0x804 --width 16 (read the 0x804 I/O port)
c. ./iow --addr 0xb2 --width 16 --value 0xE1
d. lspci -vxxx >lspci_acpi_trans ; and ./ior --addr 0x804 --width 16(read the 0x804 I/O port)
After the test, please attach the output.
Thanks.
Created attachment 19124 [details]
lspci acpi off
Created attachment 19125 [details]
lspci acpi trans
root@denisius-laptop:/usr/src/io_op# lspci -vxxx >lspci_acpi_off root@denisius-laptop:/usr/src/io_op# ./ior --addr 0x804 --width 16 the value of IO port 0x804 is 0 root@denisius-laptop:/usr/src/io_op# ./iow --addr 0xb2 --width 16 --value 0xE1 the value written into IO port 0xb2 is e1 root@denisius-laptop:/usr/src/io_op# lspci -vxxx >lspci_acpi_trans root@denisius-laptop:/usr/src/io_op# ./ior --addr 0x804 --width 16 the value of IO port 0x804 is 1 Thanks for the test. From the test it seems that some PCI config registers are changed for two PCI devices while the system is transited from legacy mode to ACPI mode(. One is the 00:00:1f.0 LPC bridge and another is RTL8169 ethernet network. For the 00:00:1f.0 LPC bridge it is expected during the transition. But why is the RTL8169 ethernet changed during the transition? Will you please try to disable some PCI devices in BIOS(For example: RTL8169, SD/MMC controller, Wireless) and see whether the system can be resumed very well? If the RTL8169 can't be disabled in BIOS, will you please not load the device driver for it and see whether the system can be resumed? Thanks. Created attachment 19143 [details]
use the RTC cmos area to track where the suspend/resume hangs
Will you please try the debug patch on the latest kernel(2.6.28-rc7) and do the following test?
a. echo 25 > /proc/cmos
b. echo mem > /sys/power/state;
c. press power button and see whether the system can be resumed.
If it can't be resumed correctly, please reboot the system. After the system is rebooted, please cat /proc/cmos and attach the output of dmesg.
thanks.
have you tried this patch for 2.6.28-rc7? during patching I have: patching file drivers/acpi/sleep/proc.c Hunk #1 succeeded at 491 with fuzz 2. Hunk #2 FAILED at 600. 1 out of 2 hunks FAILED -- saving rejects to file drivers/acpi/sleep/proc.c.rej patching file drivers/acpi/sleep/main.c Hunk #1 FAILED at 22. Hunk #2 FAILED at 255. Hunk #3 FAILED at 275. Hunk #4 FAILED at 295. 4 out of 4 hunks FAILED -- saving rejects to file drivers/acpi/sleep/main.c.rej patching file arch/x86/kernel/acpi/realmode/wakemain.c Hunk #1 succeeded at 1 with fuzz 1. Hunk #2 FAILED at 83. 1 out of 2 hunks FAILED -- saving rejects to file arch/x86/kernel/acpi/realmode/wakemain.c.rej Hi, Denys
Thi patch is generated based on 2.6.28-rc7 kernel. And it can be applied on the 2.6.28-rc7/rc8.
Will you please try it again?
thanks.
I have the same result, but I ,manually applied this patch to code. So I put echo 25 > /proc/cmos , then echo mem > /sys/power/state , after that my laptop suspended. I pushed power button, laptop started and restarted with black screen (as usual :( ). So I took out accum and put again, switch on my laptop and have cmos error. I pushed F2 for continue and when system was loaded put - cat /proc/cmos mcount=0, time=0 so it's all.... Created attachment 19406 [details]
dmesg after cmos changements
Created attachment 19415 [details]
use the RTC cmos area(0x60-64) to track where the suspend/resume hangs
Hi, Denys
thanks for the test.
From the description in comment #60 it seems that the RTC cmos area(0x40-0x44) is used by BIOS. As it can't be used by OS, it is difficult to track where suspend/resume hangs.
Will you please try the updated debug patch and do the test as mentioned in comment #57? In the debug patch the 0x60-0x64 RTC cmos area is used to track where suspend/resume hangs.
thanks.
Behavior after echo mem > /sys/power/state as usual -black screen after wake up.
but
cat /proc/cmos
mcount=225, time=fffd3800
One more little thing I had again after echo 25 > /proc/cmos CMOS checksum error. Below text which I had:
AMIBIOS(C)2006 American Megatrends, Inc.
GX700, BIOS Version: A1719IL1 Ver 1.OH
CPU Type: Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz
Press F12 key for LAN Boot
Press F11 key for Boot Menu
The MCH is operating with DDR2-667/CL5 in Dual-Channel Interleaved Mode Initializing USB Controllers .. Done.
4096MB OK
Auto-Detecting Pri Master..IDE Hard Disk
Auto-Detecting 3rd Master..ATAPI CDROM
Pri Master : FUJITSU MHY2200BH 0000000B
Ultra DMA Mode-5, S.M.A.R.T. Capable and Status OK
3rd Raster : HL-DT-ST DUDRAM GSA-T20N WA03
Ultra DMA Mode-2
Auto-detecting USB Mass Storage Devices ..
00 USB mass storage devices found and configured.
CMOS Checksum Bad
Press F1 to Run SETUP
Press F2 to continue with fail-safe settings
Created attachment 19471 [details]
24.12.2008 dmesg
Hi, Denys
Thanks for the test. It seems that there exists the error of CMOS checksum when the RTC CMOS area is used. In such case we can't know the value written to RTC cmos area. Maybe this system hangs in BIOS. But I can't confirm it.
At the same time the suspend/resume can work well on windows. To be compatible with windows, Linux had better work well.
Will you please ignore the CMOS checksum and contine to use the incorrect CMOS setting? After the box is booted, please cat /proc/cmos.
thanks.
I did it directly before I sent message here. And Checksum error I have just once after "echo 25 > /proc/cmos", then after second restart I dont see it. and as I sad before I had after "continue" this: cat /proc/cmos mcount=225, time=fffd3800 so cmos error is not problem for me :) I'm still ready for any tests! Created attachment 19519 [details] use the RTC cmos area to track where the suspend/resume hangs Will you please try this debug patch and do the test mentioned in comment #57? In this debug patch the upper 128 RTC cmos area(0x90-0x94) is used to track where suspend/resume hangs. Thanks. 1. cat /proc/cmos mcount=3, time=50311 2. echo 25 > /proc/cmos cat /proc/cmos mcount=25, time=aaaaaaaa 3. echo mem > /sys/power/state 4. Laptop has suspended, led started blinked(as usual) 5. I pushed Ente 6. Laptop started and in 2-3 seconds restarted with "black screen" (as usual) 7. I removed accum. And back it again 8. Press power on button, laptop started with CMOS checksum error 9. I press F2 to continue boot process. 10. cat /proc/cmos mcount=3, time=50311 .... So result as before echo 25 > /proc/cmos. Can it be because I removed accum during suspend or not? Or CMOS area work in volatile mode and has to store value "25" without loosing data? Please don't remove the accum. Maybe the data of CMOS area is lost after accum is removed. Thanks. I understand, but it's impossible! because after restart my laptop completly hangs, power button doesn't work... Hi, Denys
thanks for the test.
From the test it seems that the default setting will be loaded if the CMOS is accessed. In such case we can't record where suspend/resume hangs. Maybe it hangs in BIOS. But we can't confirm it.
Sorry that now I have no idea about this bug.
Thanks.
Hi, Denys Will you please try the boot option of "acpi_sleep=old_ordering"? Thanks. doesn't work Densy, please attach the dmesg output in the latest kernel, say 2.6.29-rc7 please do the same test at http://bugzilla.kernel.org/show_bug.cgi?id=12731#c27 You wrote there:
> I checked for bios updates on LG site, but latest version they have is
> A1637IL1
> version 1.63
Please say where you found new bios????? maybe there is new bios for my laptop as well :)
I tested... unfortunately it doesn't work as usual :9 Also I attached dmesg before sleep Created attachment 20639 [details]
dmesg - 2.6.29-rc8 + patch
Denys, it looks like a duplicate of bug #12731, doesn't it? I think bug #12731 it is duplicate of #11255 but not vice versa :) . And also I guess LG ED500 has a little bit another hardware configuration, but the same BIOS problem :( *** Bug 12731 has been marked as a duplicate of this bug. *** I have the same problem with LG R700 U.AP11HS Just to mention there is no need to remove the battery when it hangs on resume. You can press the power button for a few seconds and it will power off. *** Bug 11717 has been marked as a duplicate of this bug. *** *** Bug 14041 has been marked as a duplicate of this bug. *** Why exactly have you marked bug #14041 as a duplicate of this one? They are the same bug. This one contains a lot of unnecessary information and redundant comments, the new one is concise. And one of them has to live. *** Bug 14041 has been marked as a duplicate of this bug. *** Now is almost the end of 2009... I still have the same laptop LG R700, and I still don't have sleep mode working... Where we now with it? Is there any possibility to say what I should do for accelerate it?(for example make fool dump of BIOS flash or something like that). Now I'm using ubuntu 9.10 but still have this bad "legacy"... Thanks for your assistance anyway! What kind of debugging has already been done on this issue? We try to use the RTC cmos area to track where the suspend/resume hangs. And we also try the PM_TRACE to debug this issue. As the cmos checksum is incorrect, the default cmos setting is reloaded. It causes that we can't know where it hangs. But the possibility is related with BIOS. So we have no way to debug this issue. We also try the different boot options. But it still can't be resumed. a. acpi_sleep=s3_beep b. acpi_sleep=old_ordering Hi, Rafael. On 2009-09-29, at 18:35, bugzilla-daemon@bugzilla.kernel.org wrote: > --- Comment #90 from Rafael J. Wysocki <rjw@sisk.pl> 2009-09-29 > 18:35:42 --- > What kind of debugging has already been done on this issue? Well, I have some quite detailed debugging information on the bug that I reported and that was considered as a duplicate of this one. "My bug" is http://bugzilla.kernel.org/show_bug.cgi?id=11717, where I detail a lot of what has been done. Actually, I even filmed what the notebook does, but I, then, deleted it, given the 10 or more months that have already passed since I first reported this issue. I can film it again, if it is desired. I can really understand what other bug reporters feel (frustration is the right word) given that we spent so much on this. :-( My computer is not an LG one, but a Itautec Infoway N8320, which turns out to be an MSI Aesthetic 200 disguised under the hood. The bios version that it had was dated from the late 2007, if I am not mistaken and I was lucky enough to find a newer bios from this year (it is dated from 2009-03, if I remember correctly). After flashing the bios (which turned out to be an historic event, since the notebook doesn't have a floppy, its bios flasher only runs under DOS and the ready-made CDs that are around the internet are not easily customized), the problem has *NOT* gone away. This has persisted since the mid of the past year (I bought that notebook with a grant on the 28th of July and its warranty has already expired, of course), with many kernel upgrades (both from Ubuntu and Linus's git trees) and nothing works. The tests performed varied from a whole desktop environment being run down to a simple boot with init being bash only. I can provide any extra information that would help killing this darned bug. Just let me know and I will do my best with what I can (and I am sure that the other bug reporters can help with their systems). (One nice thing would be if we could distill the information that is spread on the bug reports in an organized way, with all the informations about what helps and what doesn't so that we can have a clear picture of what is being done). Regards, Rogério Brito. P.S.: Right now, I am using this iBook G3 from 2001 so that I can check e-mails, compile things etc, while the faster notebook is getting obsolete, since I depend on moving quickly from one room to another when giving lectures and talks, so that I don't mess up with the schedule of other faculty. If you need some hardware work from me on my laptop - I ready, I have qualification in this sphere, so it will not problem for me. I just want to get my laptop working correctly. Its too hard to use laptop without sleep mode. Rogério, thanks a lot for the information. Did you try any tests with /sys/power/pm_test or did you try to use PM_TRACE? Hmm. No response for a week. Hi, Rafael and other people. First some context: On Sep 29 2009, Rogério Brito wrote: > Well, I have some quite detailed debugging information on the bug > that I reported and that was considered as a duplicate of this one. > > "My bug" is http://bugzilla.kernel.org/show_bug.cgi?id=11717, where > I detail a lot of what has been done. Actually, I even filmed what > the notebook does, but I, then, deleted it, given the 10 or more > months that have already passed since I first reported this issue. > > I can film it again, if it is desired. > > I can really understand what other bug reporters feel (frustration > is the right word) given that we spent so much on this. :-( (...) On 2009-09-30, Rafael J. Wysocki wrote: > Rogério, thanks a lot for the information. > > Did you try any tests with /sys/power/pm_test or did you try to use PM_TRACE? I did a good amount of tests. Yes, I did do tests with /sys/power/pm_test. The results (in an ascii-art table) that I got with kernel 2.6.31-rc5 were: test with /s/p/pm_test | result -----------------------+------------------------ core | comes back from "sleep" processors | comes back from "sleep" devices | comes back from "sleep" "none" | hangs in the real test I'm writing this from memory, but I can repeat the tests, of course. It would be nice if other reporters also did the same, so that we can isolate the problem here. Or, if they already did the tests, it would be nice if they could summarize the tests. I also tried to use /sys/power/pm_trace, but without much success. I don't remember any hash or matches line, but I can, of course, try it again. Oh, just so that you get an idea of what happens with my computer (and I would love it if the other reporters confirmed what they are seeing), here is what happens when I press the sleep button under any kernel that I tried: ,---- | * the machine goes to sleep, staying with the light on the power button | blinking; | | * if I press the button again, the notebook gives all symptoms of | resuming; | | * just when you think that it will wake up, it turns itself off; | | * after 1 or 2 seconds, when you think that it is powered off, it | turns itself on again (yes, "out of the blue"); | | * after that, it hangs with a black screen and no responses, no | feedback, no network activity (I tried to ssh into it), no pings, no | Magic SysRq, no nothing. `---- Under Windows Vista (that came preinstalled), I do: ,---- | * press the power/sleep button; | * the machine goes to sleep; | * press the power/sleep button again; | * the machine comes from sleep. `---- I have already tried to: * enable and disable Kernel Modesetting (it's an ICH8-based chipset); * booted with a full system; * booted with init=/bin/bash (so, no acpid taking over /proc/acpi/event); * upgrade and downgrade the BIOS version; * used kernels from 2.6.24 to 2.6.31-rc8. I also tried ykzhao's suggestion of "echo mem > /sys/power/state; dmesg > dmesg_after; sync;" but, as I naively would expect, there's no time for a dmesg to be written to the disk, apparently. Oh, I read some of the other bug reports and it seems that the other posters also have a realtek 8169-driven ethernet card (can you confirm, people?). I tried "ifconfig eth0 down"'ing and even removing the module before putting it to sleep, but no success either. Well, as you can see, there's something highly magical that Windows seems to be doing here that Linux can't (up to now). As always, I am open to any suggestions and can perform any tests that you want me to (and I can reconduct anything that was done already). Thanks, Rogério Brito. As I wrote before - I have MSI motherboard in my laptop, and I can confirm that I have 8169-driven ethernet card. I'have tested sleep mode with preinstalled vista as Rogério Brito did, and I have thought - is there any chance that "preinstalled" vista has special driver for acpi/etc? And another thought is there any chance to catch how this driver put laptop to sleep mode. Thanks for the information. What about hibernation? Does it work on these boxes with recent kernels (preferably 2.6.32-rc3)? Also, Rogério, can you have a look at dmesg outputs attached by Denys and check if your system is much different from his? Hi! My laptop (LG ED500) has the same sleep/wake issue. It also has RTL8101E ethernet controller driven by r8169. Hibernation works without any problem with all kernel versions from 2.6.26 to 2.6.31 (I didn't test other versions). Tomorrow I'll check if disabling r8169 helps. There is not any options to disable Ethernet card :( and unfortunately this controller is a part of motherboard, so I cannot unplug it for testing. But I suspect that suspend problem lays in another place... what do you think - is there any reason to send mail to AMI with question about ACPI, and sleep mode implementation? Hi, people. First of all, to the bug reporters: please, let's get a bit more closer and try to join our forces. Triaging the bug report, seeing what still happens with the current kernels etc. would all be helpful if we want to get our notebooks working. OK, now to the problem itself. After some time without internet connection (humpf), I am back online and I just did a git pull and a new kernel is being baked, soon to be served. :-) I did collect quite a bunch of extra information (including newer blobs of dsdt, after the firmware upgrade from the firmware from MSI) and I will upload those in a moment. I hope that this will help us to better decide what is the culprit and how we can better address this problem (perhaps asking MSI for some involvement?). Anyway, just as an extra piece of information, my notebook is what MSI calls an MSI Aesthetic PR200 (well, at least after flashing it, that's what it reports :) and it didn't die with this upgrade). Some extra pointers (a script, actually) of what I did to create a boot USB "disk" are outlined here: http://rb.doesntexist.org/diary/2009.xhtml Hope this helps so far, Rogério Brito. Denys, your dmesg from comment #79 indicates that you use the NVidia binary graphics driver. Is this correct? On Sunday 25 October 2009, Rogério Brito wrote:
> Hi, people.
>
> First of all, to the bug reporters: please, let's get a bit more closer
> and try to join our forces.
>
> Triaging the bug report, seeing what still happens with the current
> kernels etc. would all be helpful if we want to get our notebooks
> working.
>
> OK, now to the problem itself.
>
> After some time without internet connection (humpf), I am back online
> and I just did a git pull and a new kernel is being baked, soon to be
> served. :-)
>
> I did collect quite a bunch of extra information (including newer blobs
> of dsdt, after the firmware upgrade from the firmware from MSI) and I
> will upload those in a moment.
>
> I hope that this will help us to better decide what is the culprit and
> how we can better address this problem (perhaps asking MSI for some
> involvement?).
>
> Anyway, just as an extra piece of information, my notebook is what MSI
> calls an MSI Aesthetic PR200 (well, at least after flashing it, that's
> what it reports :) and it didn't die with this upgrade).
>
> Some extra pointers (a script, actually) of what I did to create a boot
> USB "disk" are outlined here: http://rb.doesntexist.org/diary/2009.xhtml
Thanks for being persistent.
Can you please attach the output of dmesg from 2.6.32-rc5 and the output
of lspci from the system to the bug entry?
(In reply to comment #103) > Denys, your dmesg from comment #79 indicates that you use the NVidia binary > graphics driver. Is this correct? yes *** Bug 14398 has been marked as a duplicate of this bug. *** Hi. It's been quite some time since we last talked about this bug. I have some news. First, I'm including a newer dmesg here, taken with a 2.6.32-rc6 kernel. The lspci is also included. The notebook was originally an Infoway Note N8320. Now, after flashing the BIOS, it is reported as an MSI Aesthetic PR200. The older BIOS was from 2007, while this newer one is from march of this year (that is, about 2 years of differences). The notebook has no binary driver in use, and the only possible blobs that are used are those included with the kernel itself (like the ones for use with the Intel wifi card). To better show what I have been experiencing (and the other people that are seeing this bug can see if their problem is similar), I have made a short video with both the behaviour of a 2.6.32-rc8 kernel and with Windows Vista. The video is at <http://rb.doesntexist.org/linux/defective.ogv>. Sorry for the shaky video. :-( Now that I have some free time, I am available to spend some time testing things with this notebook. Rafael, if you have any questions, please, let me know. Oh, differently from Denys, I don't have an nvidia card---just a plain Intel 915. Thanks, Rogério Brito. Created attachment 23861 [details]
dmesg with a 2.6.32-rc6 kernel.
Created attachment 23862 [details]
lspci of the infoway notebook
Created attachment 23863 [details]
A summary of the hardware components of the infoway notebook
Oh, one minor thing, which is probably not related to this problem (well, I'm actually not really sure) are those messages spamming my logs: "atkbd.c: Unknown key pressed (translated set 2, code 0xf8 on isa0060/serio0)." I'm not really pressing anything. Something must be generating events there, but I don't know what (but I am willing to know more about this). Well, that's basically it. Just ask me and I will do my best to answer whatever I can. Pictures, movies, descriptions, logs etc. :-) Thanks again, Rogério Brito. I have the same weird issue.... [72786.496131] atkbd.c: Unknown key pressed (translated set 2, code 0xf1 on isa0060/serio0). [72786.496139] atkbd.c: Use 'setkeycodes e071 <keycode>' to make it known. [72786.497126] atkbd.c: Unknown key released (translated set 2, code 0xf1 on isa0060/serio0). [72786.497135] atkbd.c: Use 'setkeycodes e071 <keycode>' to make it known. Hi people, On Tue, Dec 22, 2009 at 4:03 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=11255 (...) > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |rui.zhang@intel.com Just for the record, I am available these last days of December for more tests, dumps, descriptions, whatever. I hope that we can get something fixed this year yet. :-) Regards, -- Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org well. this is a tough bug that I've not idea how to debug this so far. Rafael, any ideas? Hi, Zhang, Rafael and other people. On Tue, Dec 22, 2009 at 5:56 AM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > --- Comment #114 from Zhang Rui <rui.zhang@intel.com> 2009-12-22 07:56:41 > --- > well. this is a tough bug that I've not idea how to debug this so far. > Rafael, any ideas? Did you actually have any chance to see the video that I uploaded? I am on-line right now, so that we can exchange some e-mails quickly. Thanks, -- Rogério Brito : rbrito@{mackenzie,ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org well, I can not access to this web site... Hi, all. On Dec 28 2009, bugzilla-daemon@bugzilla.kernel.org wrote: > --- Comment #116 from Zhang Rui <rui.zhang@intel.com> 2009-12-28 08:22:45 > --- > well, I can not access to this web site... It is not clear to which web site you are referring to, but I suppose that you're talking about mine. Is that correct? It wasn't clear from the context. Anyway, the video that I posted is present at <http://rb.doesntexist.org/linux/defective.ogv>. I just tested that. Please, let me know if there is anything else that I can provide you. I suppose that the other bug reporters are also available for providing extra information so that we can kill this bug. Thanks, Is the problem still present in 2.6.37? Hi, I tried to suspend with packaged kernel of archlinux and the problem is still there. I can also try with vanilla kernel if you need. yes, please try the latest upstream kernel, say 2.6.38, to see if the problem still exists. Just for the record, with 2.6.38 (or 2.6.38.2), the problem still exists, as I said in the bug #11717. I see, though, that the kernel now has the infrastructure for saving some "almost post-mortem" data somewhere. I guess that we try to use that to see any of the final traces here. I don't have any way to use a serial console here, unfortunately. :-( Rogério, I thought you owns an Itautec Note N8320 rather than LG R700, right? As the suspend/resume problems are usually hardware dependent, I would focus on the S3 issue on LG R700 in this bug report, and let's discuss the N8320 s3 problem in bug #11717. is this okay with you? Denys Rogovchenko, your latest update is sent one and a half year ago. could you please verify if the problem still exists in the latest upstream kernel, say 2.6.38? Hi, Zhang. On Apr 20 2011, bugzilla-daemon@bugzilla.kernel.org wrote: > Rogério, > I thought you owns an Itautec Note N8320 rather than LG R700, right? > As the suspend/resume problems are usually hardware dependent, I would focus > on > the S3 issue on LG R700 in this bug report, and let's discuss the N8320 s3 > problem in bug #11717. is this okay with you? That's perfectly fine with me. I just answered it here because the bugs were, some time ago, merged together, but I am fine in continuing it there. Thanks, >
> Denys Rogovchenko,
> your latest update is sent one and a half year ago. could you please verify
> if
> the problem still exists in the latest upstream kernel, say 2.6.38?
yesterday I tried to use sleep mode in 2.6.38 kernel, ubuntu 11.04 beta 2 - so.. result the same - it doesn't work.
Denys, could you please re-do the tests in comment #43 please? Note that, for test #1, your computer should resume automatically after about 5~10 seconds, and then you can attach the dmesg output after resume. For test #2, the computer should freeze during resume as usual, and you need to hard reset the computer and then catch the dmesg output after boot. It's great that kernel bugzilla is back. Please provide the info request in comment #125. And it would be great if you can verify if the problem still exists in the latest upstream kernel. I canot run the test from #125 right now, but I can confirm that the problem still exists in debian testing kernel: Linux 3.1.0-1-amd64 #1 SMP Fri Dec 23 16:37:11 UTC 2011 x86_64 GNU/Linux. So I beleive this ticket is still relevant. May be fixed by 151b61284776be2d6f02d48c23c3625678960b97 so worth trying a current kernel again. Nope, still does not resume. Created attachment 77891 [details]
dmesg output after performing pm core test using 3.6-rc2 kernel
(In reply to comment #126) > Please provide the info request in comment #125. > And it would be great if you can verify if the problem still exists in the > latest upstream kernel. Using latest kernel from git (which is 3.6-rc2) problem still exists. test 1: dmesg output attached. test 2: no magic number found in dmesg output after reboot, and clock still shows correct time, so I assume it didn't work. Hi, Alan and others, On Tue, Oct 30, 2012 at 1:02 PM, <bugzilla-daemon@bugzilla.kernel.org> wrote: > https://bugzilla.kernel.org/show_bug.cgi?id=11255 I don't know how much this bug is related to the one that I reported (bug #11717), but it seems that they are quite a bit similar. Which information do you specifically need. Just tell me and I will try my best to collect everything that you want. If you have any script to collect the necessary data, that's even better, because the risks of me providing you with incomplete information are greatly reduced. :) Thanks, -- Rogério Brito : rbrito@{ime.usp.br,gmail.com} : GPG key 4096R/BCFCAAAA http://rb.doesntexist.org/blog : Projects : https://github.com/rbrito/ DebianQA: http://qa.debian.org/developer.php?login=rbrito%40ime.usp.br is there any luck that the problem has been fixed in the latest upstream kernel? Hi. On Jun 23 2014, bugzilla-daemon@bugzilla.kernel.org wrote: > --- Comment #133 from Zhang Rui <rui.zhang@intel.com> --- > is there any luck that the problem has been fixed in the latest upstream > kernel? As far as I am concerned (I don't know about others), the problem was already fixed as of (at least) 3.13. I may perform some git bisects if desired, to learn what the problem was. Thanks for the help, (In reply to Zhang Rui from comment #133) > is there any luck that the problem has been fixed in the latest upstream > kernel? It looks like it was fixed. The problem is not reproducible on 3.14-1-amd64 kernel from Debian. (In reply to Rogério Brito from comment #134) > As far as I am concerned (I don't know about others), the problem was > already fixed as of (at least) 3.13. I may perform some git bisects if > desired, to learn what the problem was. > (In reply to George Maizel from comment #135) > (In reply to Zhang Rui from comment #133) > > is there any luck that the problem has been fixed in the latest upstream > > kernel? > > It looks like it was fixed. The problem is not reproducible on 3.14-1-amd64 > kernel from Debian. That would be great. I will close this bug report now as it has been fixed in upstream kernel. But please feel free to attach your bisect result here. |