Bug 2438
| Summary: | Network (8139too) offline after resume | ||
|---|---|---|---|
| Product: | ACPI | Reporter: | Martin Lorenz (martin) |
| Component: | Power-Sleep-Wake | Assignee: | Luming Yu (luming.yu) |
| Status: | REJECTED DUPLICATE | ||
| Severity: | normal | CC: | acpi-bugzilla |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.5 2.6.6 2.6.7 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Attachments: |
The config of this running kernel
The loaded modules list dmesg output lspci -v -x lsdev lspci output before and after suspend lspci -vv -xx before suspend and after resume lspci -vv on HP-VT6200 before and after S3 a debug patch my dsdt (original/fixed/diff) |
||
|
Description
Martin Lorenz
2004-04-05 02:03:04 UTC
Created attachment 2500 [details]
The config of this running kernel
Simply taken from /proc/config.gz
Created attachment 2501 [details]
The loaded modules list
From /proc/modules
Created attachment 2502 [details]
dmesg output
Created attachment 2503 [details]
lspci -v -x
Created attachment 2504 [details]
lsdev
In case it has something to do with my DSDT.... here is the aoutput iasl produces for the current DSDT. root@mellon:pmtools-20031210# ../iasl-linux-20030228/iasl -dc DSDT Intel ACPI Component Architecture ASL Optimizing Compiler / AML Disassembler version 20030228 [Feb 28 2003] Copyright (C) 2000 - 2003 Intel Corporation Supports ACPI Specification Revision 2.0b Loading Acpi table from file DSDT Acpi table [DSDT] successfully installed and loaded Pass 1 parse of [DSDT] Pass 2 parse of [DSDT] Parsing Deferred Opcodes (Methods/Buffers/Packages/Regions) .................................................................................................................................................................................. Parsing completed Disassembly completed, written to "DSDT.dsl" Compiling "DSDT.dsl" DSDT.dsl 579: Field (PIUC, DWordAcc, Lock, Preserve) Error 1047 - ^ Access width is greater than region size DSDT.dsl 1266: Method (WIB1, 0, Serialized) Warning 2019 - ^ Not all control paths return a value (WIB1) DSDT.dsl 1279: Method (WOB1, 0, Serialized) Warning 2019 - ^ Not all control paths return a value (WOB1) DSDT.dsl 2109: Method (WPD0, 0, NotSerialized) Warning 2019 - ^ Not all control paths return a value (WPD0) DSDT.dsl 2152: CDA4, 16 Error 1051 - ^ Access width of Field Unit extends beyond region limit DSDT.dsl 2614: Method (_E19, 0, NotSerialized) Warning 2019 - ^ Not all control paths return a value (_E19) DSDT.dsl 2701: Method (_L03, 0, NotSerialized) Warning 2019 - ^ Not all control paths return a value (_L03) DSDT.dsl 2776: Method (_WAK, 1, NotSerialized) Warning 2026 - ^ Reserved method must return a value (_WAK) ASL Input: DSDT.dsl - 2848 lines, 90839 bytes, 1482 keywords Compilation complete. 2 Errors, 6 Warnings, 0 Remarks, 416 Optimizations Please send me the output of lspci -vv before suspend and after resuming. There is a known issue that bridge config space could be messed up accross suspend/resume cycle on some platform. --Luming Created attachment 2518 [details] lspci output before and after suspend The archive also contains the script I use for suspending: mem.sh A diff of the two lspci runs resulted in the following: 82c82 < Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr- Stepping- SERR- FastB2B- --- > Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- I don't know if I am right, but in http://www.pps.jussieu.fr/~jch/software/presario/ suggest a suspend script http://www.pps.jussieu.fr/~jch/software/presario/suspend.text that down eth0 before suspend and up eth0 on resume and is one 8139too Created attachment 2577 [details]
lspci -vv -xx before suspend and after resume
--- lspci-before.out 2004-04-14 16:42:34.000000000 +0200
+++ lspci-after.out 2004-04-14 16:47:24.000000000 +0200
@@ -115,17 +115,17 @@
0000:00:0b.0 Network controller: Harris Semiconductor Prism 2.5 Wavelan
chipset (rev 01)
Subsystem: AMBIT Microsystem Corp.: Unknown device 0200
- Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
+ 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 A routed to IRQ 9
Region 0: Memory at f4104000 (32-bit, prefetchable)
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
-00: 60 12 73 38 12 00 90 02 01 00 80 02 08 40 00 00
-10: 08 40 10 f4 00 00 00 00 00 00 00 00 00 00 00 00
+00: 60 12 73 38 02 00 90 02 01 00 80 02 00 00 00 00
+10: 08 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 68 14 00 02
-30: 00 00 00 00 dc 00 00 00 00 00 00 00 09 01 00 00
+30: 00 00 00 00 dc 00 00 00 00 00 00 00 00 01 00 00
0000:00:0c.0 USB Controller: NEC Corporation USB (rev 41) (prog-if 10 [OHCI])
Subsystem: Sharp corporation: Unknown device 102b
Tried variations of down/up eth0 in my suspend script now (with module unloading and without) but none of them made eth0 work after resume. Still using vanilla 2.6.5 kernel I have very similar problem with S3 and 8139too on HP VT6200 notebook (P4M, ALi chipset). I've tried 2.6.5 and 2.6.6-rc2-mm2 with and without 8139too module unloading. Created attachment 2746 [details]
lspci -vv on HP-VT6200 before and after S3
You might want to try 2.6.6-rc3-mm1. It includes my patch for the 8139too to allow you to suspend without the interface running/setup. It may fix your problems. It probably won't do you much good if you're suspending while the interface is up and running though. Tried 2.6.6-rc3-mm1... ...no change new kernel 2.6.6-mm1 ...no change Created attachment 2893 [details]
a debug patch
please try the debug patch, just want to verify if the root cause is PCI
configuration problem
hmmmm after applying the patch the system doesent go to S3 at all Does you mean that patch break the S3 suspend issue? It sounds odd. --Luming so... I did several things now. first of all I applied the debug patch and got some odd behaviour: on the first try to suspend it aborts suspending due to one process that it cannot kill giving it a second try it suspends with the same behaviour as before than i tried to fix my dsdt and applied the initrd patch from gaugsch.at (the one for 2.6.5 applies with one off-target hunk) the DSDT I compiled produces this error on startup:May 19 16:40:50 mellon kernel: checking if image is initramfs...it isn't (ungzip failed); looks like an initrd May 19 16:40:50 mellon kernel: ACPI: Looking for DSDT in initrd ... found customized DSDT with 11899 bytes! May 19 16:40:50 mellon kernel: Freeing initrd memory: 11k freed May 19 16:40:50 mellon kernel: NET: Registered protocol family 16 May 19 16:40:50 mellon kernel: PCI: PCI BIOS revision 2.10 entry at 0xfd8ae, last bus=0 May 19 16:40:50 mellon kernel: PCI: Using configuration type 1 May 19 16:40:50 mellon kernel: mtrr: v2.0 (20020519) May 19 16:40:50 mellon kernel: ACPI: Subsystem revision 20040326 May 19 16:40:50 mellon kernel: ACPI: Overriding _OS definition Linux May 19 16:40:50 mellon kernel: ACPI: Using customized DSDT May 19 16:40:50 mellon kernel: tbutils-0196: *** Warning: Invalid checksum in table [DSDT] (6E, sum B7 is not zero) May 19 16:40:50 mellon kernel: tbget-0299: *** Info: Table [DSDT] replaced by host OS May 19 16:40:50 mellon kernel: tbxface-0117 [03] acpi_load_tables : ACPI Tables successfully acquired May 19 16:40:50 mellon kernel: Parsing all Control Methods:......................................................................................................nssea rch-0307: *** Error: ns_search_and_enter: Bad character in ACPI Name: FEFF3850 May 19 16:40:50 mellon kernel: psargs-0352: *** Error: Looking up [0xFEFF3850] (NON-ASCII) May 19 16:40:50 mellon kernel: in namespace, AE_BAD_CHARACTER May 19 16:40:50 mellon kernel: search_node c11e43c8 start_node c11e43c8 return_node c11e43c8 May 19 16:40:50 mellon kernel: psparse-1133: *** Error: Method execution failed [\_SI_._SST] (Node c11e43c8), AE_BAD_CHARACTER May 19 16:40:50 mellon kernel: dsinit-0145 [09] ds_init_one_object : Method c11e43c8 [_SST] - parse failure, AE_BAD_CHARACTER May 19 16:40:50 mellon kernel: ...... May 19 16:40:50 mellon kernel: Table [DSDT](id F004) - 397 Objects with 40 Devices 108 Methods 17 Regions May 19 16:40:50 mellon kernel: ACPI Namespace successfully loaded at root c0392cbc May 19 16:40:50 mellon kernel: ACPI: IRQ9 SCI: Level Trigger. May 19 16:40:50 mellon kernel: evxfevnt-0093 [04] acpi_enable : Transition to ACPI mode successful May 19 16:40:50 mellon kernel: evgpeblk-0867 [06] ev_create_gpe_block : GPE 00 to 63 [_GPE] 8 regs at 0000000000008018 on int 9 May 19 16:40:50 mellon kernel: evgpeblk-0925 [06] ev_create_gpe_block : Found 0 Wake, Enabled 3 Runtime GPEs in this block May 19 16:40:50 mellon kernel: Completing Region/Field/Buffer/Package initialization:....................................................... May 19 16:40:50 mellon kernel: Initialized 17/17 Regions 0/0 Fields 12/12 Buffers 26/26 Packages (406 nodes) May 19 16:40:51 mellon kernel: Executing all Device _STA and_INI methods:.......................................... May 19 16:40:51 mellon kernel: 42 Devices found containing: 42 _STA, 2 _INI methods May 19 16:40:51 mellon kernel: ACPI: Interpreter enabled May 19 16:40:51 mellon kernel: ACPI: Using PIC for interrupt routing Hmmm, you are hacking DSDT. Do you mind showing me what's the exact changes you did ? And I also want to know why you want to hack your DSDT? Thanks Luming Well... This was my first try on DSDT hacking. I found such a lot of statements about buggy dsdt's so I got myself iasl and tried to recompile mine. And guess what: it gave some errors and warnings. So the reason is, that I wondered if some of my problems were caused by bugs in the DSDT and whether I was able to fix it. I will post a diff of the actual changes I made as soon as I get back home because, this is where my notebook is at the moment. I followed the various HOWTO's and FAQ's on DSDT fixing creaping around out there. The complaints iasl issued are also in http://bugme.osdl.org/show_bug.cgi?id=2438#c6. All I did was trying to get rid of those and setting the _OS string to a length that would be recognised as WinXP. Created attachment 2989 [details]
my dsdt (original/fixed/diff)
I've applied this patch http://bugzilla.kernel.org/attachment.cgi?id=3263&action=view on top of 2.6.7-mm3 and now my network card works after resume. No need to unload/reload the module. Thank you! Did the same (apply patch http://bugzilla.kernel.org/attachment.cgi?id=3263&action=view) on top of 2.6.7 vanilla. Fixed this bug for me too! thanks. *** This bug has been marked as a duplicate of 2643 *** |