Bug 11255 - S3: no resume, not even a beep - LG R700
S3: no resume, not even a beep - LG R700
Status: CLOSED CODE_FIX
Product: Power Management
Classification: Unclassified
Component: Hibernation/Suspend
All Linux
: P1 high
Assigned To: power-management_other
:
: 12731 14398 (view as bug list)
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2008-08-05 23:57 UTC by Denys Rogovchenko
Modified: 2014-06-26 12:31 UTC (History)
12 users (show)

See Also:
Kernel Version: 3.6-rc2
Tree: Mainline
Regression: No


Attachments
dmesg (38.91 KB, text/plain)
2008-08-07 02:50 UTC, Denys Rogovchenko
Details
acpi dump (100.93 KB, text/plain)
2008-08-07 02:56 UTC, Denys Rogovchenko
Details
new dmesg :) (124.19 KB, text/plain)
2008-08-12 02:31 UTC, Denys Rogovchenko
Details
try the debug patch (1.21 KB, patch)
2008-08-13 02:27 UTC, ykzhao
Details | Diff
dmesg with patch and debug start kernel parameters (124.73 KB, text/plain)
2008-08-14 00:59 UTC, Denys Rogovchenko
Details
dmesg without any start parameters (41.03 KB, text/plain)
2008-08-14 03:49 UTC, Denys Rogovchenko
Details
new one (69.96 KB, text/plain)
2008-08-20 23:16 UTC, Denys Rogovchenko
Details
try the debug patch (3.32 KB, patch)
2008-08-25 02:04 UTC, ykzhao
Details | Diff
kernel with first and second patches (70.30 KB, text/plain)
2008-08-25 12:02 UTC, Denys Rogovchenko
Details
try the custom DSDT (183.45 KB, patch)
2008-08-26 20:04 UTC, ykzhao
Details | Diff
dmesg after dsdt replacing (42.32 KB, text/plain)
2008-08-27 03:46 UTC, Denys Rogovchenko
Details
try the debug patch (2.17 KB, patch)
2008-08-28 20:12 UTC, ykzhao
Details | Diff
dmesg (40.16 KB, text/plain)
2008-08-29 21:55 UTC, Denys Rogovchenko
Details
hibernate works!!! (41.97 KB, text/plain)
2008-08-30 02:13 UTC, Denys Rogovchenko
Details
dmesg for test 1. (121.27 KB, text/plain)
2008-10-14 13:46 UTC, Denys Rogovchenko
Details
try the debug patch in which the waking vector is set after the _PTS object (3.74 KB, patch)
2008-11-19 01:25 UTC, ykzhao
Details | Diff
use the attached tool to read I/O port (2.47 KB, patch)
2008-12-02 21:57 UTC, ykzhao
Details | Diff
lspci acpi off (33.62 KB, application/octet-stream)
2008-12-03 10:52 UTC, Denys Rogovchenko
Details
lspci acpi trans (33.62 KB, application/octet-stream)
2008-12-03 10:53 UTC, Denys Rogovchenko
Details
use the RTC cmos area to track where the suspend/resume hangs (5.60 KB, patch)
2008-12-04 00:30 UTC, ykzhao
Details | Diff
dmesg after cmos changements (85.77 KB, text/plain)
2008-12-21 01:25 UTC, Denys Rogovchenko
Details
use the RTC cmos area(0x60-64) to track where the suspend/resume hangs (5.66 KB, patch)
2008-12-21 21:06 UTC, ykzhao
Details | Diff
24.12.2008 dmesg (33.34 KB, text/plain)
2008-12-24 07:57 UTC, Denys Rogovchenko
Details
use the RTC cmos area to track where the suspend/resume hangs (7.50 KB, patch)
2008-12-29 01:57 UTC, ykzhao
Details | Diff
dmesg - 2.6.29-rc8 + patch (52.79 KB, text/plain)
2009-03-23 05:52 UTC, Denys Rogovchenko
Details
dmesg with a 2.6.32-rc6 kernel. (45.74 KB, text/plain)
2009-11-21 23:25 UTC, Rogério Brito
Details
lspci of the infoway notebook (43.56 KB, text/plain)
2009-11-21 23:26 UTC, Rogério Brito
Details
A summary of the hardware components of the infoway notebook (18.01 KB, text/plain)
2009-11-21 23:28 UTC, Rogério Brito
Details
dmesg output after performing pm core test using 3.6-rc2 kernel (73.93 KB, text/plain)
2012-08-18 08:40 UTC, George Maizel
Details

Description Denys Rogovchenko 2008-08-05 23:57:29 UTC
Latest working kernel version:?
Earliest failing kernel version:2.6.25
Distribution:
Hardware Environment:Laptop - "LG R700 U.AP55R1"
Software Environment:Ubuntu Hardy 8.04 with latest updates
Problem Description:


groob's kernel parameters: root=/dev/sda5 ro vga=0x0369 ec_intr=0 elevator=as resume=swap:/dev/sda7

dmesg: ...

 ACPI: bus type pci registered
[    0.153976] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[    0.153976] PCI: Not using MMCONFIG.
[    0.153976] PCI: Using configuration type 1 for base access
[    0.154633] ACPI: EC: Look up EC in DSDT
[    0.161295] ACPI: Interpreter enabled
[    0.161303] ACPI: (supports S0 S1 S3 S4 S5)
[    0.161324] ACPI: Using IOAPIC for interrupt routing
[    0.161384] PCI: MCFG configuration 0: base e0000000 segment 0 buses 0 - 255
[    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 [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff81013fc17a00), AE_NOT_EXIST
[    0.162909] ACPI Error (evregion-0316): No handler for Region [EC__] (ffff81013fc153a8) [EmbeddedControl] [20080321]
[    0.162926] ACPI Error (exfldio-0290): Region EmbeddedControl(3) has no handler [20080321]
[    0.162940] ACPI Error (psparse-0530): Method parse/execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff81013fc17a00), AE_NOT_EXIST
[    0.162975] ACPI Error (uteval-0233): Method execution failed [\_SB_.PCI0.SBRG.EC__.BAT1._STA] (Node ffff81013fc17a00), AE_NOT_EXIST
[    0.162975] PCI: MCFG area at e0000000 reserved in ACPI motherboard resources
[    0.170807] PCI: Using MMCONFIG at e0000000 - efffffff
[    0.172973] ACPI: EC: non-query interrupt received, switching to interrupt mode
[    0.175973] ACPI: EC: GPE storm detected, disabling EC GPE
[    0.181004] ACPI: EC: GPE = 0x17, I/O: command/status = 0x66, data = 0x62
[    0.181004] ACPI: EC: driver started in poll mode
[    0.181004] ACPI: PCI Root Bridge [PCI0] (0000:00)
[    0.182482] pci 0000:00:1f.0: quirk: region 0800-087f claimed by ICH6 ACPI/GPIO/TCO


suspend&hibernate don't work as well....

Steps to reproduce:boot kernel, dmesg | grep ACPI
Comment 1 Denys Rogovchenko 2008-08-06 00:07:11 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>
Comment 2 Zhang Rui 2008-08-06 18:11:23 UTC
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.
Comment 3 Denys Rogovchenko 2008-08-07 02:50:17 UTC
Created attachment 17116 [details]
dmesg

dmesg
Comment 4 Denys Rogovchenko 2008-08-07 02:56:05 UTC
Created attachment 17117 [details]
acpi dump

acpi dump
Comment 5 Denys Rogovchenko 2008-08-07 02:58:19 UTC
It seems that in my laptop LG company put MSI motherboard... but I don't know is it help or not.... 
Comment 6 Zhang Rui 2008-08-11 22:19:30 UTC
Please make sure CONFIG_ACPI_DEBUG is set in your kernel config and boot with "acpi.debug_layer=0x44 acpi.debug_level=0x8800001f"
Comment 7 Denys Rogovchenko 2008-08-12 00:55:32 UTC
Well, should I attach after that dmesg and acpidump again?
Comment 8 Zhang Rui 2008-08-12 01:07:51 UTC
Please just attach the dmesg output. :)
Comment 9 Denys Rogovchenko 2008-08-12 02:31:37 UTC
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
Comment 10 ykzhao 2008-08-13 02:27:53 UTC
Created attachment 17209 [details]
try the debug patch

Will you please try the debug patch and attach the output of dmesg?
Thanks.
Comment 11 ykzhao 2008-08-13 02:29:53 UTC
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.
Comment 12 Denys Rogovchenko 2008-08-13 11:57:52 UTC
So, if it is not a regression, is it really that you cannot help?
Comment 13 Denys Rogovchenko 2008-08-14 00:59:34 UTC
Created attachment 17227 [details]
dmesg with patch and debug start kernel parameters
Comment 14 ykzhao 2008-08-14 02:58:19 UTC
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.
Comment 15 ykzhao 2008-08-14 03:06:45 UTC
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.
Comment 16 ykzhao 2008-08-14 03:08:09 UTC
Hi, Denys
    Will you please confirm whether the system can be shutdown correctly?
    Thanks.
Comment 17 Denys Rogovchenko 2008-08-14 03:27:47 UTC
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...
Comment 18 Denys Rogovchenko 2008-08-14 03:49:35 UTC
Created attachment 17238 [details]
dmesg without any start parameters
Comment 19 ykzhao 2008-08-15 00:30:28 UTC
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.

Comment 20 Denys Rogovchenko 2008-08-20 23:16:05 UTC
Created attachment 17351 [details]
new one

debug_initcall
Comment 21 Denys Rogovchenko 2008-08-21 22:31:13 UTC
I have tried 2.6.27-rc4 kernel - the same situation... sleep and hibernate didn't work....
Comment 22 ykzhao 2008-08-25 02:04:12 UTC
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.
Comment 23 ykzhao 2008-08-25 02:05:16 UTC
As it is not a regression, clear the flag of regression.
Comment 24 Denys Rogovchenko 2008-08-25 12:02:40 UTC
Created attachment 17440 [details]
kernel with first and second patches

sleep & hibernate don't  still work...
Comment 25 ykzhao 2008-08-25 19:07:31 UTC
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.
Comment 26 Denys Rogovchenko 2008-08-26 02:19:02 UTC
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.
Comment 27 ykzhao 2008-08-26 20:04:49 UTC
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.
Comment 28 Denys Rogovchenko 2008-08-27 03:46:44 UTC
Created attachment 17478 [details]
dmesg after dsdt replacing

I have the same result as with native dsdt table...
Comment 29 Denys Rogovchenko 2008-08-27 03:59:35 UTC
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.
Comment 30 ykzhao 2008-08-28 20:12:26 UTC
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.
Comment 31 Denys Rogovchenko 2008-08-29 21:55:38 UTC
Created attachment 17537 [details]
dmesg
Comment 32 Denys Rogovchenko 2008-08-30 02:13:12 UTC
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.
Comment 33 Denys Rogovchenko 2008-08-30 02:19:15 UTC
So, wait mode still doesn't work...
Comment 34 ykzhao 2008-08-30 07:27:53 UTC
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.
Comment 35 Denys Rogovchenko 2008-08-30 07:34:31 UTC
Well, I tried hibernate without patch in comment#30, but with first patch and  "resume=/dev/sda7" start prameter...
Comment 36 ykzhao 2008-08-31 20:34:33 UTC
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.
Comment 37 ykzhao 2008-09-16 01:14:31 UTC
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.
Comment 38 Denys Rogovchenko 2008-09-17 02:48:51 UTC
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. 
Comment 39 Denys Rogovchenko 2008-10-01 10:31:00 UTC
Hello ykzhao  
Comment 40 Denys Rogovchenko 2008-10-01 10:32:21 UTC
I just want to know is this problem still under your coverage or not...
Comment 41 Zhang Rui 2008-10-05 19:56:37 UTC
denys,
please try the patch at http://marc.info/?l=linux-acpi&m=122307130419749&w=2
and see if it helps.
Comment 42 Denys Rogovchenko 2008-10-13 02:17:48 UTC
:( 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.


Comment 43 ykzhao 2008-10-13 19:44:10 UTC
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.

      
Comment 44 Denys Rogovchenko 2008-10-14 13:46:59 UTC
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...
Comment 45 Denys Rogovchenko 2008-10-14 14:36:34 UTC
Test number 2 - the same situation as in suspend mode... I have to unplug/plug accumulator and after that normal cold start...
Comment 46 Len Brown 2008-10-24 23:20:09 UTC
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
Comment 47 ykzhao 2008-10-27 02:42:09 UTC
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.
Comment 48 Denys Rogovchenko 2008-11-17 04:01:36 UTC
Ie tried 2.6.28.rc5 - same result, doesn´t work
Comment 49 ykzhao 2008-11-19 01:25:24 UTC
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.
Comment 50 Denys Rogovchenko 2008-11-21 03:17:57 UTC
patch (id=18926) doesn´t help me..
Comment 51 ykzhao 2008-11-23 05:49:27 UTC
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.
Comment 52 ykzhao 2008-12-02 21:57:13 UTC
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.
Comment 53 Denys Rogovchenko 2008-12-03 10:52:40 UTC
Created attachment 19124 [details]
lspci acpi off
Comment 54 Denys Rogovchenko 2008-12-03 10:53:20 UTC
Created attachment 19125 [details]
lspci acpi trans
Comment 55 Denys Rogovchenko 2008-12-03 10:54:04 UTC
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
Comment 56 ykzhao 2008-12-03 18:40:29 UTC
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.
Comment 57 ykzhao 2008-12-04 00:30:29 UTC
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.
Comment 58 Denys Rogovchenko 2008-12-09 22:13:04 UTC
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
Comment 59 ykzhao 2008-12-15 00:32:26 UTC
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. 
Comment 60 Denys Rogovchenko 2008-12-21 01:23:55 UTC
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....
Comment 61 Denys Rogovchenko 2008-12-21 01:25:45 UTC
Created attachment 19406 [details]
dmesg after cmos changements
Comment 62 ykzhao 2008-12-21 21:06:03 UTC
Created attachment 19415 [details]
use the RTC cmos area(0x60-64) to track where the suspend/resume hangs
Comment 63 ykzhao 2008-12-21 21:10:51 UTC
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.
Comment 64 Denys Rogovchenko 2008-12-24 07:55:47 UTC
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
Comment 65 Denys Rogovchenko 2008-12-24 07:57:18 UTC
Created attachment 19471 [details]
24.12.2008 dmesg
Comment 66 ykzhao 2008-12-24 23:01:57 UTC
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.
Comment 67 Denys Rogovchenko 2008-12-25 07:52:28 UTC
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!
Comment 68 ykzhao 2008-12-29 01:57:40 UTC
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.
Comment 69 Denys Rogovchenko 2009-01-04 18:54:50 UTC
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?


Comment 70 ykzhao 2009-01-05 01:36:57 UTC
Please don't remove the accum.
Maybe the data of CMOS area is lost after accum is removed.
Thanks.
Comment 71 Denys Rogovchenko 2009-01-05 03:16:04 UTC
I understand, but it's impossible! because after restart my laptop completly hangs, power button doesn't work...
Comment 72 ykzhao 2009-01-14 19:29:47 UTC
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.
Comment 73 ykzhao 2009-03-04 18:17:29 UTC
Hi, Denys
   Will you please try the boot option of "acpi_sleep=old_ordering"?
   Thanks.
Comment 74 Denys Rogovchenko 2009-03-10 19:31:08 UTC
doesn't work
Comment 75 Zhang Rui 2009-03-17 01:01:59 UTC
Densy,
please attach the dmesg output in the latest kernel, say 2.6.29-rc7
Comment 76 Zhang Rui 2009-03-23 02:18:22 UTC
please do the same test at http://bugzilla.kernel.org/show_bug.cgi?id=12731#c27
Comment 77 Denys Rogovchenko 2009-03-23 03:09:12 UTC
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 :)
Comment 78 Denys Rogovchenko 2009-03-23 05:51:17 UTC
I tested... unfortunately it doesn't work as usual :9

Also I attached dmesg before sleep
Comment 79 Denys Rogovchenko 2009-03-23 05:52:14 UTC
Created attachment 20639 [details]
dmesg - 2.6.29-rc8 + patch
Comment 80 Zhang Rui 2009-03-24 18:25:29 UTC
Denys, it looks like a duplicate of bug #12731, doesn't it?
Comment 81 Denys Rogovchenko 2009-03-25 09:03:22 UTC
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 :(
Comment 82 Zhang Rui 2009-03-30 07:25:24 UTC
*** Bug 12731 has been marked as a duplicate of this bug. ***
Comment 83 bill 2009-05-21 22:50:31 UTC
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.
Comment 84 ykzhao 2009-08-31 14:06:23 UTC
*** Bug 11717 has been marked as a duplicate of this bug. ***
Comment 85 ykzhao 2009-09-07 02:22:17 UTC
*** Bug 14041 has been marked as a duplicate of this bug. ***
Comment 86 Rafael J. Wysocki 2009-09-15 19:11:15 UTC
Why exactly have you marked bug #14041 as a duplicate of this one?
Comment 87 Artem S. Tashkinov 2009-09-16 05:52:10 UTC
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.
Comment 88 Artem S. Tashkinov 2009-09-21 03:57:14 UTC
*** Bug 14041 has been marked as a duplicate of this bug. ***
Comment 89 Denys Rogovchenko 2009-09-29 12:43:06 UTC
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!
Comment 90 Rafael J. Wysocki 2009-09-29 18:35:42 UTC
What kind of debugging has already been done on this issue?
Comment 91 ykzhao 2009-09-30 00:54:22 UTC
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
Comment 92 Rogério Brito 2009-09-30 02:12:08 UTC
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.
Comment 93 Denys Rogovchenko 2009-09-30 08:58:47 UTC
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.
Comment 94 Rafael J. Wysocki 2009-09-30 21:12:23 UTC
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?
Comment 95 Rafael J. Wysocki 2009-10-06 21:11:32 UTC
Hmm.  No response for a week.
Comment 96 Rogério Brito 2009-10-07 05:57:47 UTC
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.
Comment 97 Denys Rogovchenko 2009-10-07 06:36:02 UTC
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.
Comment 98 Rafael J. Wysocki 2009-10-07 20:00:43 UTC
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?
Comment 99 George Maizel 2009-10-07 22:16:38 UTC
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.
Comment 100 Denys Rogovchenko 2009-10-08 17:06:14 UTC
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...
Comment 101 Denys Rogovchenko 2009-10-24 16:32:38 UTC
what do you think - is there any reason to send mail to AMI with question about ACPI, and sleep mode implementation?
Comment 102 Rogério Brito 2009-10-25 00:08:33 UTC
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.
Comment 103 Rafael J. Wysocki 2009-10-26 19:52:00 UTC
Denys, your dmesg from comment #79 indicates that you use the NVidia binary graphics driver.  Is this correct?
Comment 104 Rafael J. Wysocki 2009-10-26 19:53:43 UTC
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?
Comment 105 Denys Rogovchenko 2009-10-30 20:43:22 UTC
(In reply to comment #103)
> Denys, your dmesg from comment #79 indicates that you use the NVidia binary
> graphics driver.  Is this correct?

yes
Comment 106 ykzhao 2009-11-06 06:42:58 UTC
*** Bug 14398 has been marked as a duplicate of this bug. ***
Comment 107 Rogério Brito 2009-11-21 23:22:10 UTC
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.
Comment 108 Rogério Brito 2009-11-21 23:25:12 UTC
Created attachment 23861 [details]
dmesg with a 2.6.32-rc6 kernel.
Comment 109 Rogério Brito 2009-11-21 23:26:51 UTC
Created attachment 23862 [details]
lspci of the infoway notebook
Comment 110 Rogério Brito 2009-11-21 23:28:02 UTC
Created attachment 23863 [details]
A summary of the hardware components of the infoway notebook
Comment 111 Rogério Brito 2009-11-21 23:31:44 UTC
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.
Comment 112 Denys Rogovchenko 2009-11-28 16:57:55 UTC
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.
Comment 113 Rogério Brito 2009-12-22 07:53:36 UTC
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
Comment 114 Zhang Rui 2009-12-22 07:56:41 UTC
well. this is a tough bug that I've not idea how to debug this so far.
Rafael, any ideas?
Comment 115 Rogério Brito 2009-12-22 08:17:57 UTC
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
Comment 116 Zhang Rui 2009-12-28 08:22:45 UTC
well, I can not access to this web site...
Comment 117 Rogério Brito 2009-12-28 15:57:28 UTC
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,
Comment 118 Rafael J. Wysocki 2011-01-16 22:49:27 UTC
Is the problem still present in 2.6.37?
Comment 119 bill 2011-02-06 12:52:39 UTC
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.
Comment 120 Zhang Rui 2011-04-19 07:44:23 UTC
yes, please try the latest upstream kernel, say 2.6.38, to see if the problem still exists.
Comment 121 Rogério Brito 2011-04-19 16:07:45 UTC
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. :-(
Comment 122 Zhang Rui 2011-04-20 01:47:49 UTC
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?
Comment 123 Rogério Brito 2011-04-20 02:34:36 UTC
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,
Comment 124 Denys Rogovchenko 2011-04-20 11:07:22 UTC
> 
> 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.
Comment 125 Zhang Rui 2011-04-22 02:14:16 UTC
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.
Comment 126 Zhang Rui 2012-01-18 01:37:18 UTC
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.
Comment 127 George Maizel 2012-01-18 18:48:05 UTC
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.
Comment 128 Alan 2012-08-08 09:41:01 UTC
May be fixed by 151b61284776be2d6f02d48c23c3625678960b97 so worth trying a current kernel again.
Comment 129 George Maizel 2012-08-17 19:27:12 UTC
Nope, still does not resume.
Comment 130 George Maizel 2012-08-18 08:40:10 UTC
Created attachment 77891 [details]
dmesg output after performing pm core test using 3.6-rc2 kernel
Comment 131 George Maizel 2012-08-18 08:44:48 UTC
(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.
Comment 132 Rogério Brito 2012-10-30 15:23:37 UTC
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
Comment 133 Zhang Rui 2014-06-23 13:17:17 UTC
is there any luck that the problem has been fixed in the latest upstream kernel?
Comment 134 Rogério Brito 2014-06-23 14:08:43 UTC
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,
Comment 135 George Maizel 2014-06-26 09:22:09 UTC
(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.
Comment 136 Zhang Rui 2014-06-26 12:31:30 UTC
(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.

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