Bug 6431
| Summary: | Shutdown hangs on an ACPI error, if Marvell 88E8053 (sky2) enabled | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Rodolphe Keller (keikoz) |
| Component: | Network | Assignee: | Stephen Hemminger (stephen) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | acpi-bugzilla, bugs, bunk, morgan.collett, Pitxyoki, s3321037, stephen, trenn |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.25 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
| Bug Depends on: | |||
| Bug Blocks: | 56331 | ||
|
Description
Rodolphe Keller
2006-04-23 08:34:44 UTC
One of these two Match() statements is failing (returning Ones), and the ASL
code does not check for the error:
Store (Match (DerefOf (Index (TIM0, 0x01)), MEQ, Arg0, MTR, 0x00, 0x00),
Local6)
Store (Match (DerefOf (Index (TIM0, 0x02)), MEQ, Arg3, MTR, 0x00, 0x00),
Local6)
I added these two blocks of code, one after each statement to catch the error:
if (LEqual (Local6, Ones))
{
Store ("No Match found with Arg0", Debug)
Store (Arg0, Debug)
Return (0)
}
if (LEqual (Local6, Ones))
{
Store ("No Match found with Arg3", Debug)
Store (Arg3, Debug)
Return (0)
}
Either Arg0 or Arg3 does not match an integer within the TIM0 package. Both of
these come from PCI config space, namely PMRI and PSRI fields. There may be
some problem reading these values.
OperationRegion (CFG2, PCI_Config, 0x40, 0x20)
Field (CFG2, DWordAcc, NoLock, Preserve)
{
PMPT, 4,
PSPT, 4,
PMRI, 6,
Offset (0x02),
SMPT, 4,
SSPT, 4,
SMRI, 6,
Offset (0x04),
PSRI, 4,
An execution trace of the \_SB_PCI0.IDE0.CHN0._GTM would help.
So this works if you drop the old (ACPI-enabled) 2.6.13 kernel onto the failing system? Clearly X is changing some state that is confusing the AML that is executed on the way down, and apparently the BIOS AML is not ready for it. Any chance you can update your DSDT per Bob's comments to see if it gets any further? Alternatively, you could enable CONFIG_ACPI_DEBUG=y and right before your shutdown you can enable acpi_dbg_layer and acpi_dbg_level via /proc/acpi (enable all the bits and kick off the shutdown, it will be verbose, but you should get the last thing run at the end of the console log). Thanks for replying. Well I was trying to figure out what I could do to anwser to Robert's comment :) Actually: > An execution trace of the \_SB_PCI0.IDE0.CHN0._GTM would help How can I give you this info ? > Any chance you can update your DSDT per Bob's comments to see > if it gets any further? I will try to update the DSDT and see what happens. I'm just learning how to do it ;) so let me some time. > Alternatively, you could enable > CONFIG_ACPI_DEBUG=y and right before your shutdown you can > enable acpi_dbg_layer and acpi_dbg_level via /proc/acpi > (enable all the bits and kick off the shutdown, it will > be verbose, but you should get the last thing run at the > end of the console log). I just did it; it was _very_ verbose; the last lines i could see before it hangs are: hwregs-0071 [6904] [02] hw_clear_acpi_status : ---- Entry hwregs-0614 [6904] [03] hw_register_write : ---- Entry hwregs-0713 [6904] [03] hw_register_write : ---- Exit- AE_OK evgpeblk-0141 [6904] [03] ev_walk_gpe_list : ---- Entry evgpeblk-0168 [6904] [03] ev_walk_gpe_list : ---- Exit- AE_OK hwregs-0110 [6904] [02] hw_clear_acpi_status : ---- Entry hwgpe-0371 [6904] [02] hw_disable_all_gpes : ---- Entry evgpeblk-0141 [6904] [03] ev_walk_gpe_list : ---- Entry evgpeblk-0168 [6904] [03] ev_walk_gpe_list : ---- Exit- AE_OK evgpeblk-0141 [6904] [03] ev_walk_gpe_list : ---- Entry evgpeblk-0168 [6904] [03] ev_walk_gpe_list : ---- Exit- AE_OK hwgpe-0375 [6904] [02] hw_disable_all_gpes : ---- Exit- AE_OK hwgpe-0416 [6904] [02] hw_enable_all_wakeup_g: ---- Entry evgpeblk-0141 [6904] [03] ev_walk_gpe_list : ---- Entry evgpeblk-0168 [6904] [03] ev_walk_gpe_list : ---- Exit- AE_OK hwgpe-0419 [6904] [02] hw_enable_all_wakeup_g: ---- Exit- AE_OK hwregs-0501 [6904] [02] hw_register_read : ---- Entry hwregs-0592 [6904] [02] hw_register_read : ---- Exit- AE_OK hwsleep-0283 [6904] [01] enter_sleep_state : Entering sleep state [S5] hwregs-0614 [6904] [02] hw_register_write : ---- Entry hwregs-0713 [6904] [02] hw_register_write : ---- Exit- AE_OK hwregs-0614 [6904] [02] hw_register_write : ---- Entry hwregs-0713 [6904] [02] hw_register_write : ---- Exit- AE_OK hwregs-0614 [6904] [02] hw_register_write : ---- Entry Yep, verbosity is the key to finding a needle in a haystack. We will need a trace of the entire execution of the method, all X megabytes worth. Fortunately, ascii compresses very well. Hi, About the DSDT: Well, i tried to change the DSDT, and to recompile it (i guess i did it correctly, since i had no more warnings when compiling it: here is the changed dsdt.dsl file: http://keikoz.free.fr/new_dsdt.dsl ). I included it in the kernel source, compiled, and run it, but the problem is still here; hangs on shutdown, with the exactly same message. About the debug messages: All I can read is what i pasted in my last message. A lot of lines come out, and when the system hangs, that's what i can see. I can't find a way to read all the lines scrolling before it hangs; I suppose there is a way to recover all thus lines that i can't read, but how to do it ? Since the fs aren't mounted at that moment, and logging is finished, i can't find them in any log message, i really can't figure out how to see them. I have exactly the same issue on Debian with vanilla Kernel 2.6.16.19-smp. Compiled with ACPI. Hardware (very similar to Rodolphe's one): - P4, 3.0 Ghz (with HyperThreading) - MB: Asus P5GD1, 1 Gb of DDR2, with Intel i915P (Northbridge) and ICH6R (Southbridge) - WinFast PCI-Express Graphic card with NVidia GeForce 6600TD chip Software - Debian + vanilla Kernel 2.6.16.19-smp, XFree86, KDE 3.2, drivers - nvidia module, but the same problem happens with vesa driver. Problem Description: Exactly the same as Rodolphe's one I believe so far my logs could give no additional information. What kind of information and experiments could help the resolution? Well, The problem evolved ... but is not solved in fact. Some time ago, i tried to downgrade my bios, because i discovered that the one I was using was a beta version (Asus didn't mention it was a betaversion on its download page, and it is still presented as stable). I was using the 1011 for P5GDC Deluxe, and i downgrade to 1010, which is stable. After that it seemed to solve the problem: I could start X, and shutdown the desktop normally. But in fact, the problem is still present when i let the desktop on some hours. After some hours of uptime, I still can't shutdown properly. I didn't worked so much more on this problem, since it isn't critical, and I anyway searched for several month without finding a solution. Now, I can't find a solution to recover the last debug messages. There are thousands of messages, but I have no more console, filesystem shells to copy them. I'd like try opening a serial console from another desktop, with a null-modem cable, which could let me see the last messages when everything is going down. That's the only way I found for giving an entire execution trace to Robert and Len. Is there a simplest way ? Hello, it took me some time, but here is my serial port log. http://calvrack.narod.ru/acpi_log_poweroff.txt.gz It is not the best hosting possible. If you want, I could repost it to the other place. What else could I do to help you with this bug? Thanks in advance BR, Alexander Hi, I also have the same issue on debian with recent kernel since 2.6.14, and it troubled with vanilla 2.6.17.7, too. Below is my environment spec. CPU: P4 3.0GHz MB: GA-8I915P Pro (Rev 1.x) North: i915P, South: ICH6. VGA: Leadtek WinFast PX6600 TD PCI-E (NVIDIA GeForce 6600) Software: Debian etch, vanilla 2.6.17.7, Xorg 7.0, Gnome 2.14.2, NVIDIA Linux x86 Kernel Module 1.0-8762 . Problem Description: The same as above. Here's my log: (it's too verbose, uncompressed size: 669K) http://netcenter.ncnu.edu.tw/~alextwl/acpi_poweroff.txt.gz and dsdt.dsl: http://netcenter.ncnu.edu.tw/~alextwl/dsdt.dsl Please let me know if I can help in any other way. Thanks. Regard, tang. I could find a way to obtain all the final messages. I know, it did took a lot of time :) My shutdown logs: http://keikoz.free.fr/linux-res/log_error.txt.gz My dsdt decompiled file: http://keikoz.free.fr/linux-res/dsdt.dsl An Ubuntu bug (https://launchpad.net/distros/ubuntu/+source/linux-source-2.6.15/+bug/43961) is linked to this bug but I don't see any reference here to the Ubuntu bug. It's occurring on both Ubuntu Dapper and Edgy and affects numerous people, from laptops to desktops and even possibly a server. There are several other Ubuntu bugs logged on this issue, marked as duplicates and linked off the bug I referenced. Hopefully this will give some additional data points and users who can provide debug information. It occurs on my Sony Vaio VGN-S460 (a.k.a. PCG-6G4L) which can reboot but not shut down. On ubuntu dapper (which uses 2.6.15) > * Will now halt > md: stopping all md devices > Shutdown: hdb > ACPI-0517: *** Error: Method parse/execution failed [\_SB_PCI0.IDE0.GTM_] (node dffe6f60), AE_AML_PACKAGE_LIMIT > ACPI-0517: *** Error: Method parse/execution failed [\_SB_PCI0.IDE0.CHN0._GTM] (node dffe6380), AE_AML_PACKAGE_LIMIT > Shutdown: hda > ACPI-0517: *** Error: Method parse/execution failed [\_SB_PCI0.IDE0.GTM_] (node dffe6f60), AE_AML_PACKAGE_LIMIT > ACPI-0517: *** Error: Method parse/execution failed [\_SB_PCI0.IDE0.CHN0._GTM] (node dffe6380), AE_AML_PACKAGE_LIMIT Not sure whether this is an ACPI bug. I saw something similar when disk got set up. But this was a libata code problem invoking _STM and _GTM in wrong order: https://bugzilla.novell.com/show_bug.cgi?id=216853 AFAIK the ide and ata ACPI patches are not mainline but are like in SUSE kernels included in Ubuntu. You should be able to workaround above disk ACPI errors with: ide=noacpi libata.ata_acpi=0 Best use both, not sure whether ide or ata ACPI patches are affected (latter probably is even not included in 2.6.15 kernel, parameter just gets ignored then). You shouldn't see above errors any more then? But probably still cannot shutdown because it's another unrelated problem to the shutdown issue? About the ACPI debug error log: hwsleep-0283 [4B40] [01] enter_sleep_state : Entering sleep state [S5] hwregs-0614 [4B40] [02] hw_register_write : ----Entry hwregs-0854 [4B40] [02] hw_low_level_write : Wrote: 00001C01 width 16 to 0000000000000804 (SystemIO) hwregs-0713 [4B40] [02] hw_register_write : ----Exit- AE_OK hwregs-0614 [4B40] [02] hw_register_write : ----Entry hwregs-0713 [4B40] [02] hw_register_write : ----Exit- AE_OK hwregs-0614 [4B40] [02] hw_register_write : ----Entry Not sure, I also have a shutdown problem and looked at these code parts. Mine was always spinning at reading WAK_STS, the endless loop, when the machine should already have shut down. It looks like your's does not come that far and shortly before stops. IIRC there should come some other ACPI reads/writes to some registers, but the Intel ACPI people know better about that..., just guesses from my side. Hi, I have some new info which may help. I need first to explain that, additionally to this shutdown problem, i have a bug with the driver (sky2) of my ethernet card (an onboard chip, Marvell 88E8053 Gigabit Ethernet Controller). The bug is already reported here: http://bugzilla.kernel.org/show_bug.cgi?id=7647 The point is that, being bored by this ethernet problem, i recently bought a new ethernet card (D-Link), and i disactivated the Marvel chip in the BIOS. From that moment the shutdown problem seems to be solved oO. Couldn't this shutdown problem be related to the problem with the ethernet driver ? Not using the Marvel chip seems to solve the issue for me ... keikoz This surely puts a new perspective on the matter for me... I always thought the problem's cause was related to X (I'm using Xorg) and my Asus N6600 Silencer (Nvidia GeForce 6600 GPU). But come to think of it this problem started after switching from a debian kernel (2.6.8-3 I think) to one that had sky2 compiled into it and upgraded to a more recent (evil) Nvidia driver. Before that I had to compile the sk98lin module and had no problems. So maybe something happened while merging the code pertaining to the card? My motherboard is an Asus P5GPL with an onboard Marvell 88E8053 Gigabit Ethernet Controller (from dmesg: sky2 v1.5 addr 0xcaefc000 irq 177 Yukon-EC (0xb6) rev 2). I don't remember coming across bug 7647. Sorry I'm just a suser (stupid user) with subpar knowledge but willing to help anyway I can. Stephen, can you look at comments #13 and #14? I have never seen this problem on all the Marvell systems I have/use. What is the kernel config? There have been fixes to the driver relating to power setting on shutdown and more recently Wake On Lan support has been added. I generally use the gentoo patched sources, so i just managed to make a complete test with a vanilla. I installed a vanilla kernel 2.6.20.1, with this configuration: http://keikoz.free.fr/linux-res/config-2.6.20-gentoo As result, i can tell that the problem doesn't depend on the sky2 driver. It just depends on whether the Marvell chip is enabled in the bios or not. If i disable the chip, everything goes fine, the desktop shutdown normally. If the Marvell chip is enabled in the BIOS, the desktop hangs on shutdown (using or not the sky2 driver). The problem starts with the 2.6.14 kernel series on and is still the same with 2.6.20. I have always used a debian patched kernel (which is currently 2.6.18-4-686 on my system) with NVidia's driver patch. On Rodolphe Keller's note.. Switching off the on board ethernet from BIOS lets me shutdown the computer normally after prolonged X use (over an hour or more). Re-enabling the ethernet chip brings back the problem (i.e. computer hangs after echoing "acpi_power_off called"). Please reproduce with a 2.6.20.6 or later kernel without Nvidia driver. There have been lots of changes in sky2 driver over the last 2years since 2.6.18 Is there any difference if you compile the sky2 driver as a module and remove it before shutdown? Thanks, Ray closing due to inactivity, please reopen when more recent kernels have been tested (current target would be 2.6.23-rc1) This still happens under Debian Lenny with a 2.6.22-2-686 SMP kernel. I find the solution is still to disable the ethernet card on the BIOS. Sorry, I forgot to mention my system specs: Motherboard: "ASUS P5GDC-V Deluxe" Ethernet Card: "Marvell® 88E8053 PCIe Gigabit LAN Controller" Sorry, I forgot to mention my system specs: Motherboard: "ASUS P5GDC-V Deluxe" Ethernet Card: "Marvell® 88E8053 PCIe Gigabit LAN Controller" The sky2 driver will enable wake-on-lan if the BIOS has it enables. So there might be a problem there. It would be interesting to know if problem still occurs on 2.6.24-rc2? An additional bit of data would be to see if problem still occurs if you use the vendor version of sk98lin driver. Sorry, I'm just a begginer (~1 year and some months) to linux. Can you tell me how can I do that? I'm using the Debian testing branch's current kernel [1] but I'd like to be able to help... If you could give me some info on how to use that driver, I could try to do it. [1] - http://packages.debian.org/lenny/linux-image-2.6.22-3-686 To get vendor driver: Download from http://www.syskonnect.de/e_en/support/driver.html (Choose one of PCI-Express boards, Driver, Linux) Unpack the tarball. I believe there are instructions in it for building driver. also, could you please try as comment# 20 said and tell us the result? thanks. I haven't tried to use the vendor's driver yet, as I haven't had much time lately... Anyway, I unloaded the current driver from the kernel (using modprobe -r sky2) and nothing changed: the computer does not poweroff as it should. Blacklisting the module (adding it to /etc/modprobe.d/blacklist) does nothing either. I might try to compile the vendor's module next week or so. Hi, Pitxyoki Will you please try the latest kernel and see whether the problem still exists? If it still exists, please set CONFIG_ACPI_DEBUG and CONFIG_ACPI_DEBUG_FUNC_TRACE in .config and do the following test: a. After the system is booted, echo 0x02000002 > /sys/module/acpi/parameters/debug_layer and echo 0x00200014 > /sys/module/acpi/parameters/debug_level b. execute the command of "poweroff" It will be great if you can get the output through the serial console. Thanks. I can confirm this problem is still present on 2.6.24 (debian build). I have recompiled the kernel with those options enabled but I can't echo to those files: -- # echo 0x02000002 > /sys/module/acpi/parameters/debug_layer bash: /sys/module/acpi/parameters/debug_layer: No such file or directory # echo 0x00200014 > /sys/module/acpi/parameters/debug_level bash: /sys/module/acpi/parameters/debug_level: No such file or directory -- The tests I did now got me the same behaviour as before: - If I login to a gnome session, there is no way to shutdown properly - If I disable the network adapter on the BIOS, all ways to shutdown (through gnome's shutdown menu, using shutdown -h, poweroff, ...) work OK. - If I add blacklist sky2 to /etc/modprobe.d/blacklist, the module is not loaded but all results to these tests is are the same - If only gdm is started, I can shutdown properly - If I login to icewm, I _CAN_ shutdown properly - If I login to enlightenment, I _CAN_ shutdown properly I still haven't tried KDE, but my guess is this seems to be a gnome-only problem. I'm sorry, the echo command does work. I just had booted the wrong kernel. :s Anyway, I don't have a "null-modem cable"... Is there any way to redirect the output to the serial console to somewhere else where I can get it? Hi, Pitxyoki
Thanks for the confirm.That echo command can't work is caused by disabling the debug function of ACPI.
Will you please set the CONFIG_ACPI_DEBUG and
CONFIG_ACPI_DEBUG_FUNC_TRACE in .config and do the test as required in the comment #31?
Thanks.
Please read comment #33. The tests I mentioned on #32 were all done with those options set on .config and gave the exact same results. HI, Pitxyoki
Will you please try the latest kernel(2.6.25-rc9) and see whether the problem still exists?
Thanks.
Hi, Sorry for the late response, I've been a bit busy lately. I'm using the 2.6.25 kernel now (from the debian experimental branch) and I can confirm the exact same problem is present. Hi, Pitxyoki
Thanks for the test.
According to the description the system can be shutdown correctl if the Marvell ethernet is disabled in BIOS. Whether the driver is loaded has no effect. The problem is related with the Marvell ethernet driver or the hardware. And the problem is not caused by ACPI.
So the bug will be reassigned to the Driver category.
Any progress on this issue? I have a P5AD2 system running Gnome and can confirm this bug as well. Anything I can do to track down whats specifically causing this? Sounds like a wake on lan problem. Since wake-on-lan is enabled by default, have you tried disabling it. WOL is disabled, and it still refuses to shut down. Does it work with vendor sk98lin driver from: http://www.skd.de/e_en/support/driver.html It is a bit of a pain to build install the vendor driver, but the vendor has more information available and may set registers differently. If it works with one driver and not the other it is possible to do binary search down to find which register settings are causing the problem. When testing vendor driver: * use only sky2 or sk98lin at a time (two drivers same hardware == trouble) * start from complete cold power off (pull plug) Using the 2.6.26 kernel from Debian Lenny, I'm NOT experiencing this bug anymore. Thank you all! Good news. :) Close this bug. |