Bug 2438

Summary: Network (8139too) offline after resume
Product: ACPI Reporter: Martin Lorenz (martin)
Component: Power-Sleep-WakeAssignee: 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
Distribution: Debian (unstable)
Hardware Environment: Sharp PC-MM10 (Cursoe powered)
Software Environment: udev 022, hotplug 20040329, module-list attached
Problem Description: 

I fiddle around with suspend/resume for quite a while now on this cute little
machine and finally got it going with some workarounds...
BUT: the network is not to be reactivated after one suspend/resume cycle

Steps to reproduce:
* boot
* ifup eth0 (network is not enabled for faster unplugged bootup)
* stop alsa (necessary workaround)
* unload orinoco modules (necessary workaround)
* unload ohci and ehci modules (necessary workaround)
* sync && echo -n mem > /sys/power/state
* press power button to resume
==> ifconfig reports interface but no transfer possible...
Comment 1 Martin Lorenz 2004-04-05 02:13:03 UTC
Created attachment 2500 [details]
The config of this running kernel

Simply taken from /proc/config.gz
Comment 2 Martin Lorenz 2004-04-05 02:18:47 UTC
Created attachment 2501 [details]
The loaded modules list

From /proc/modules
Comment 3 Martin Lorenz 2004-04-05 02:19:43 UTC
Created attachment 2502 [details]
dmesg output
Comment 4 Martin Lorenz 2004-04-05 02:22:29 UTC
Created attachment 2503 [details]
lspci -v -x
Comment 5 Martin Lorenz 2004-04-05 02:23:12 UTC
Created attachment 2504 [details]
lsdev
Comment 6 Martin Lorenz 2004-04-05 02:28:49 UTC
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
Comment 7 Luming Yu 2004-04-06 01:32:53 UTC
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 
Comment 8 Martin Lorenz 2004-04-06 01:55:17 UTC
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-
Comment 9 Sérgio M Basto 2004-04-06 11:39:25 UTC
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
Comment 10 Martin Lorenz 2004-04-14 08:07:08 UTC
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
Comment 11 Martin Lorenz 2004-04-15 00:31:35 UTC
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
Comment 12 Marek Lotke 2004-04-29 02:07:26 UTC
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.  
Comment 13 Marek Lotke 2004-04-29 02:09:37 UTC
Created attachment 2746 [details]
lspci -vv on HP-VT6200 before and after S3
Comment 14 Adrian Yee 2004-05-03 01:04:32 UTC
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.
Comment 15 Martin Lorenz 2004-05-03 05:17:22 UTC
Tried 2.6.6-rc3-mm1...
...no change
Comment 16 Martin Lorenz 2004-05-13 05:33:26 UTC
new kernel 2.6.6-mm1
...no change
Comment 17 Shaohua 2004-05-18 00:04:31 UTC
Created attachment 2893 [details]
a debug patch

please try the debug patch, just want to verify if the root cause is PCI
configuration problem
Comment 18 Martin Lorenz 2004-05-19 00:59:54 UTC
hmmmm
after applying the patch the system doesent go to S3 at all
Comment 19 Luming Yu 2004-05-19 01:52:12 UTC
Does you mean that patch break the S3 suspend issue?
It sounds odd.
--Luming
Comment 20 Martin Lorenz 2004-05-19 11:51:56 UTC
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

Comment 21 Luming Yu 2004-05-25 23:51:52 UTC
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
Comment 22 Martin Lorenz 2004-05-26 01:15:59 UTC
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.
Comment 23 Martin Lorenz 2004-05-27 03:40:14 UTC
Created attachment 2989 [details]
my dsdt (original/fixed/diff)
Comment 24 Marek Lotke 2004-06-28 04:49:37 UTC
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! 
Comment 25 Martin Lorenz 2004-06-28 05:58:08 UTC
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.
Comment 26 Luming Yu 2004-06-28 23:21:24 UTC

*** This bug has been marked as a duplicate of 2643 ***