Bug 6431 - Shutdown hangs on an ACPI error, if Marvell 88E8053 (sky2) enabled
Summary: Shutdown hangs on an ACPI error, if Marvell 88E8053 (sky2) enabled
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Network (show other bugs)
Hardware: i386 Linux
: P2 normal
Assignee: Stephen Hemminger
URL:
Keywords:
Depends on:
Blocks: 56331
  Show dependency tree
 
Reported: 2006-04-23 08:34 UTC by Rodolphe Keller
Modified: 2013-04-09 06:13 UTC (History)
8 users (show)

See Also:
Kernel Version: 2.6.25
Subsystem:
Regression: ---
Bisected commit-id:


Attachments

Description Rodolphe Keller 2006-04-23 08:34:44 UTC
Hi, dear developers

Most recent kernel where this bug did not occur:2.6.13.5

Distribution: I'm using Gentoo (~x86), but the problem happens on Ubuntu
(Dapper) too. (I guess it is distro-independent).

Hardware Environment:
- P4, 3.2 Ghz (Intel 640, with EMT64, and Hyperthreading)
- MB: Asus P5GDC-Deluxe, 1 Gb of DDR2, with Intel i915P (Northbridge) and ICH6
(southbridge)
- WinFast PCI-Express Graphic card with NVidia GeForce 6600TD chip

Software Environment:
Gentoo, using 2.6.16 actually (vanilla sources); Xorg 7.0 (the problem was
already there with 6.8), Gnome 2.12.3 (but same pbl with kde). I use the nvidia
module, but the exactly same problem happens with the nv free driver of xorg.

Problem Description:
When i shutdown the desktop, it hangs at shutdown. The desktop doesn't power
off. This happens with all shutdown methods (init 0, halt, shutdown -h, shutdown
from gnome logout-screen). The reboot works normally.
But the problem happens only if i start X. If it has been started, there is no
way to shutdown properly, even killing X before the shutdown, unloading the
module, killing gdm/kdm/xdm ... 
I have some messages on shutdown which might help. The messages are different on
gentoo and ubuntu (hope it can help).

On gentoo (with acpi-debug messages enabled in the kernel):
> shutdown hdb
> shutdown hda
> [ACPI Debug] String: [0x04] "SIOS"
> Power down.
> acpi_power_off called
> hwsleep-0283 [01] enter_sleep_state [S5]

And it hangs there...

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
> Power down.
> acpi_power_off called

And it hangs there ...


Steps to reproduce:
- Start X (in any way, by startx, by starting xdm/gdm, and opening gnome/kde:
BUT if i _only_ open the gdm login screen, and directly shutdown without
starting gnome/kde i can shutdown properly)
- shutdown (in any way, and Xorg being still up, or stopped/killed)

My dmesg :
Linux version 2.6.16-gentoo-r3 (root@localhost) (version gcc 3.4.6 (Gentoo
3.4.6-r1, ssp-3.4.5-1.0, pie-8.7.9)) #1 SMP PREEMPT Sun Apr 23 15:10:19 UTC 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000003ffb0000 (usable)
 BIOS-e820: 000000003ffb0000 - 000000003ffbe000 (ACPI data)
 BIOS-e820: 000000003ffbe000 - 000000003fff0000 (ACPI NVS)
 BIOS-e820: 000000003fff0000 - 0000000040000000 (reserved)
 BIOS-e820: 00000000ffb80000 - 0000000100000000 (reserved)
127MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000ff780
On node 0 totalpages: 262064
  DMA zone: 4096 pages, LIFO batch:0
  DMA32 zone: 0 pages, LIFO batch:0
  Normal zone: 225280 pages, LIFO batch:31
  HighMem zone: 32688 pages, LIFO batch:7
DMI 2.3 present.
ACPI: RSDP (v000 ACPIAM                                ) @ 0x000fb030
ACPI: RSDT (v001 A M I  OEMRSDT  0x10000513 MSFT 0x00000097) @ 0x3ffb0000
ACPI: FADT (v001 A M I  OEMFACP  0x10000513 MSFT 0x00000097) @ 0x3ffb0200
ACPI: MADT (v001 A M I  OEMAPIC  0x10000513 MSFT 0x00000097) @ 0x3ffb0390
ACPI: OEMB (v001 A M I  AMI_OEM  0x10000513 MSFT 0x00000097) @ 0x3ffbe040
ACPI: MCFG (v001 A M I  OEMMCFG  0x10000513 MSFT 0x00000097) @ 0x3ffb6e10
ACPI: DSDT (v001  A0045 A0045001 0x00000001 INTL 0x02002026) @ 0x00000000
ACPI: PM-Timer IO Port: 0x808
ACPI: Local APIC address 0xfee00000
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
Processor #0 15:4 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 15:4 APIC version 20
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode:  Flat.  Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 50000000 (gap: 40000000:bfb80000)
Built 1 zonelists
Kernel command line: root=/dev/hda1
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 65536 bytes)
Detected 3212.141 MHz processor.
Using pmtmr for high-res timesource
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 1034520k/1048256k available (2664k kernel code, 13092k reserved, 852k
data, 208k init, 130752k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 6435.80 BogoMIPS (lpj=12871607)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: bfebfbff 20000000 00000000 00000000 0000649d
00000000 00000000
CPU: After vendor identify, caps: bfebfbff 20000000 00000000 00000000 0000649d
00000000 00000000
monitor/mwait feature present.
using mwait in idle threads.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 20000000 00000000 00000180 0000649d
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU0: Intel P4/Xeon Extended MCE MSRs (24) available
CPU0: Thermal monitoring enabled
Checking 'hlt' instruction... OK.
 tbxface-0109 [02] load_tables           : ACPI Tables successfully acquired
Parsing all Control Methods:
Table [DSDT](id 0005) - 742 Objects with 56 Devices 193 Methods 24 Regions
ACPI Namespace successfully loaded at root c04c9fd0
evxfevnt-0091 [03] enable                : Transition to ACPI mode successful
CPU0: Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 03
Booting processor 1/1 eip 2000
Initializing CPU#1
Calibrating delay using timer specific routine.. 6423.26 BogoMIPS (lpj=12846529)
CPU: After generic identify, caps: bfebfbff 20000000 00000000 00000000 0000649d
00000000 00000000
CPU: After vendor identify, caps: bfebfbff 20000000 00000000 00000000 0000649d
00000000 00000000
monitor/mwait feature present.
CPU: Trace cache: 12K uops, L1 D cache: 16K
CPU: L2 cache: 2048K
CPU: Physical Processor ID: 0
CPU: After all inits, caps: bfebfbff 20000000 00000000 00000180 0000649d
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#1.
CPU1: Intel P4/Xeon Extended MCE MSRs (24) available
CPU1: Thermal monitoring enabled
CPU1: Intel(R) Pentium(R) 4 CPU 3.20GHz stepping 03
Total of 2 processors activated (12859.06 BogoMIPS).
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
checking TSC synchronization across 2 CPUs: passed.
Brought up 2 CPUs
migration_cost=4000
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xf0031, last bus=4
PCI: Using MMCONFIG
ACPI: Subsystem revision 20060127
evgpeblk-0941 [06] ev_create_gpe_block   : GPE 00 to 1F [_GPE] 4 regs on int 0x9
evgpeblk-1037 [05] ev_initialize_gpe_bloc: Found 11 Wake, Enabled 0 Runtime GPEs
in this block
Completing Region/Field/Buffer/Package
initialization:.............................................................................................................................................................................
Initialized 23/24 Regions 30/30 Fields 43/43 Buffers 77/78 Packages (751 nodes)
Executing all Device _STA and_INI
methods:............................................................
60 Devices found - executed 0 _STA, 0 _INI methods
ACPI: Interpreter enabled
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller 0000:00:1f.1
Boot video device is 0000:04:00.0
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P1._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P3._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P4._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P0P5._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKC] (IRQs *3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 *5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 11 12 14 15) *0, disabled.
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 *5 6 7 10 11 12 14 15)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 19 devices
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
pnp: 00:08: ioport range 0x290-0x297 has been reserved
PCI: Bridge: 0000:00:01.0
  IO window: e000-efff
  MEM window: caf00000-cfffffff
  PREFETCH window: d0000000-dfffffff
PCI: Bridge: 0000:00:1c.0
  IO window: d000-dfff
  MEM window: disabled.
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.1
  IO window: c000-cfff
  MEM window: cae00000-caefffff
  PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
  IO window: a000-bfff
  MEM window: cad00000-cadfffff
  PREFETCH window: 50000000-500fffff
acpi_bus-0201 [01] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
acpi_bus-0201 [01] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
acpi_bus-0201 [01] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.1 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
Machine check exception polling timer started.
audit: initializing netlink socket (disabled)
audit(1145809626.100:1): initialized
highmem bounce pool size: 64 pages
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:01.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:01.0:pcie00]
Allocate Port Service[0000:00:01.0:pcie03]
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
Allocate Port Service[0000:00:1c.0:pcie03]
ACPI: PCI Interrupt 0000:00:1c.1[B] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.1 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.1:pcie00]
Allocate Port Service[0000:00:1c.1:pcie02]
Allocate Port Service[0000:00:1c.1:pcie03]
Real Time Clock Driver v1.12ac
ACPI: Power Button (FF) [PWRF]
ACPI: Power Button (CM) [PWRB]
Parsing all Control Methods:
Table [SSDT](id 0038) - 10 Objects with 0 Devices 4 Methods 0 Regions
ACPI: Processor [CPU1] (supports 8 throttling states)
Parsing all Control Methods:
Table [SSDT](id 003A) - 10 Objects with 0 Devices 4 Methods 0 Regions
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:02:00.0 to 64
sky2 v1.1 addr 0xcaefc000 irq 17 Yukon-EC (0xb6) rev 2
sky2 eth0: addr 00:11:d8:5b:f4:c6
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH6: IDE controller at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH6: chipset revision 3
ICH6: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
    ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
input: AT Translated Set 2 keyboard as /class/input/input0
hda: WDC WD1200JB-00GVC0, ATA DISK drive
hdb: WDC WD1200JB-00FUA0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
IT8212: IDE controller at PCI slot 0000:01:04.0
ACPI: PCI Interrupt 0000:01:04.0[A] -> GSI 23 (level, low) -> IRQ 19
IT8212: chipset revision 19
it821x: controller in pass through mode.
IT8212: 100% native mode on irq 19
    ide2: BM-DMA at 0xa400-0xa407, BIOS settings: hde:pio, hdf:pio
    ide3: BM-DMA at 0xa408-0xa40f, BIOS settings: hdg:pio, hdh:pio
Probing IDE interface ide2...
hde: _NEC DVD_RW ND-4550A, ATAPI CD/DVD-ROM drive
hdf: CRD-8522B, ATAPI CD/DVD-ROM drive
ide2 at 0xb800-0xb807,0xb402 on irq 19
Probing IDE interface ide3...
Probing IDE interface ide1...
Probing IDE interface ide3...
hda: max request size: 512KiB
hda: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100)
hda: cache flushes supported
 hda: hda1 hda2 < hda5 hda6 >
hdb: max request size: 512KiB
hdb: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63, UDMA(100)
hdb: cache flushes supported
 hdb: hdb1 hdb2 < hdb5 hdb6 >
hde: ATAPI 40X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
hdf: ATAPI 48X CD-ROM drive, 128kB Cache
ACPI: PCI Interrupt 0000:01:03.0[A] -> GSI 21 (level, low) -> IRQ 20
ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[20]  MMIO=[caddf800-caddffff]  Max
Packet=[2048]  IR/IT contexts=[4/8]
ieee1394: raw1394: /dev/raw1394 device initialized
acpi_bus-0201 [01] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 128 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: irq 19, io mem 0xcacff800
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
USB Universal Host Controller Interface driver v2.3
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 19, io base 0x00007000
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 21, io base 0x00007400
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x00007800
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 16, io base 0x00008000
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usbcore: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
MC: drivers/edac/edac_mc.c version edac_mc  Ver: 2.0.0 Apr 23 2006
Advanced Linux Sound Architecture Driver Version 1.0.11rc2 (Wed Jan 04 08:57:20
2006 UTC).
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1b.0 to 64
ALSA device list:
  #0: HDA Intel at 0xcacf4000 irq 16
oprofile: using NMI interrupt.
NET: Registered protocol family 2
IP route cache hash table entries: 65536 (order: 6, 262144 bytes)
TCP established hash table entries: 262144 (order: 9, 3145728 bytes)
TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
TCP: Hash tables configured (established 262144 bind 65536)
TCP reno registered
ip_conntrack version 2.4 (8189 buckets, 65512 max) - 172 bytes per conntrack
TCP bic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
p4-clockmod: P4/Xeon(TM) CPU On-Demand Clock Modulation available
Starting balanced_irq
Using IPI Shortcut mode
ieee1394: Host added: ID:BUS[0-00:1023]  GUID[0011d8000004016a]
kjournald starting.  Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 208k freed
libata version 1.20 loaded.
nvidia: module license 'NVIDIA' taints kernel.
ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:04:00.0 to 64
NVRM: loading NVIDIA Linux x86 Kernel Module  1.0-8756  Wed Mar 29 14:26:26 PST 2006
ata_piix 0000:00:1f.2: version 1.05
acpi_bus-0201 [01] bus_set_power         : Device is not power manageable
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 21
PCI: Setting latency timer of device 0000:00:1f.2 to 64
ata1: SATA max UDMA/133 cmd 0x9800 ctl 0x9402 bmdma 0x8400 irq 21
ata2: SATA max UDMA/133 cmd 0x9000 ctl 0x8802 bmdma 0x8408 irq 21
ATA: abnormal status 0x7F on port 0x9807
ata1: disabling port
scsi0 : ata_piix
ATA: abnormal status 0x7F on port 0x9007
ata2: disabling port
scsi1 : ata_piix
Adding 979924k swap on /dev/hda5.  Priority:-1 extents:1 across:979924k
EXT3 FS on hda1, internal journal
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdb5, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdb6, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
sky2 eth0: enabling interface
sky2 eth0: Link is up at 10 Mbps, full duplex, flow control none
i2c_adapter i2c-1: SMBus Quick command not supported, can't probe for chips
i2c_adapter i2c-2: SMBus Quick command not supported, can't probe for chips
i2c_adapter i2c-3: SMBus Quick command not supported, can't probe for chips
w83627ehf 9191-0290: Increasing fan 3 clock divider from 1 to 2
w83627ehf 9191-0290: fan1 clock divider changed from 128 to 8
w83627ehf 9191-0290: fan2 clock divider changed from 4 to 8
w83627ehf 9191-0290: Increasing fan 0 clock divider from 8 to 16
w83627ehf 9191-0290: Increasing fan 3 clock divider from 2 to 4
w83627ehf 9191-0290: Increasing fan 0 clock divider from 16 to 32
w83627ehf 9191-0290: Increasing fan 3 clock divider from 4 to 8
w83627ehf 9191-0290: Increasing fan 0 clock divider from 32 to 64
w83627ehf 9191-0290: Increasing fan 3 clock divider from 8 to 16
w83627ehf 9191-0290: Increasing fan 0 clock divider from 64 to 128
w83627ehf 9191-0290: Increasing fan 3 clock divider from 16 to 32
w83627ehf 9191-0290: Increasing fan 3 clock divider from 32 to 64
w83627ehf 9191-0290: Increasing fan 3 clock divider from 64 to 128

My dsdt.dsl (maybee useful?) : http://keikoz.free.fr/dsdt.dsl

I dont know what other info could be useful; just tell me.

Regards, 

Rodolphe Keller
Comment 1 Robert Moore 2006-04-25 13:08:50 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.

Comment 2 Len Brown 2006-04-26 19:29:17 UTC
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).

Comment 3 Rodolphe Keller 2006-04-28 01:18:08 UTC
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
Comment 4 Robert Moore 2006-04-28 12:53:13 UTC
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.
Comment 5 Rodolphe Keller 2006-05-03 03:28:36 UTC
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.
Comment 6 Alexander Pimenov 2006-06-21 13:04:34 UTC
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?
Comment 7 Rodolphe Keller 2006-06-22 11:45:40 UTC
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 ?
Comment 8 Alexander Pimenov 2006-06-27 12:18:36 UTC
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
Comment 9 Wei-li Tang 2006-07-31 19:29:10 UTC
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.
Comment 10 Rodolphe Keller 2006-08-10 04:58:24 UTC
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
Comment 11 Morgan Collett 2006-11-17 00:26:00 UTC
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.
Comment 12 Thomas Renninger 2006-12-04 02:29:33 UTC
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.
Comment 13 Rodolphe Keller 2007-03-03 08:11:43 UTC
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
Comment 14 Nomad 2007-03-05 14:15:15 UTC
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.
Comment 15 Adrian Bunk 2007-03-05 18:13:18 UTC
Stephen, can you look at comments #13 and #14?
Comment 16 Stephen Hemminger 2007-03-06 11:16:58 UTC
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.
Comment 17 Rodolphe Keller 2007-03-10 04:28:40 UTC
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.
Comment 18 Nomad 2007-03-13 10:54:45 UTC
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").
Comment 19 Stephen Hemminger 2007-04-10 10:12:30 UTC
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
Comment 20 Zhang Rui 2007-07-11 00:37:45 UTC
Is there any difference if you compile the sky2 driver as a module
and remove it before shutdown?

Thanks,
Ray
Comment 21 Daniel Drake 2007-07-27 16:20:26 UTC
closing due to inactivity, please reopen when more recent kernels have been tested (current target would be 2.6.23-rc1)
Comment 22 Pitxyoki 2007-11-11 06:41:02 UTC
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.
Comment 23 Pitxyoki 2007-11-11 11:55:25 UTC
Sorry, I forgot to mention my system specs:
Motherboard: "ASUS P5GDC-V Deluxe"
Ethernet Card: "Marvell® 88E8053 PCIe Gigabit LAN Controller"
Comment 24 Pitxyoki 2007-11-11 11:55:36 UTC
Sorry, I forgot to mention my system specs:
Motherboard: "ASUS P5GDC-V Deluxe"
Ethernet Card: "Marvell® 88E8053 PCIe Gigabit LAN Controller"
Comment 25 Stephen Hemminger 2007-11-13 10:52:30 UTC
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?
Comment 26 Stephen Hemminger 2007-12-07 13:54:04 UTC
An additional bit of data would be to see if problem still occurs if you use the vendor version of sk98lin driver.
Comment 27 Pitxyoki 2007-12-07 16:05:09 UTC
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
Comment 28 Stephen Hemminger 2007-12-07 17:50:55 UTC
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.
Comment 29 Fu Michael 2007-12-09 18:33:00 UTC
also, could you please try as comment# 20 said and tell us the result? thanks.
Comment 30 Pitxyoki 2007-12-18 03:11:19 UTC
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.
Comment 31 ykzhao 2008-02-02 00:37:37 UTC
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.
Comment 32 Pitxyoki 2008-02-03 15:25:45 UTC
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.
Comment 33 Pitxyoki 2008-02-03 16:00:29 UTC
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?
Comment 34 ykzhao 2008-02-03 16:50:51 UTC
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.
Comment 35 Pitxyoki 2008-02-04 08:54:22 UTC
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.
Comment 36 ykzhao 2008-04-15 00:11:00 UTC
HI, Pitxyoki
    Will you please try the latest kernel(2.6.25-rc9) and see whether the problem still exists?
    Thanks.
Comment 37 Pitxyoki 2008-06-01 04:04:32 UTC
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.
Comment 38 ykzhao 2008-06-04 19:48:48 UTC
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. 
     
Comment 39 Fabio Catarinella 2008-07-06 07:03:46 UTC
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?
Comment 40 Stephen Hemminger 2008-07-06 18:14:46 UTC
Sounds like a wake on lan problem. Since wake-on-lan is enabled by default, have you tried disabling it.
Comment 41 Fabio Catarinella 2008-07-07 14:16:04 UTC
WOL is disabled, and it still refuses to shut down.
Comment 42 Stephen Hemminger 2008-07-07 15:01:21 UTC
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)
Comment 43 Pitxyoki 2008-09-23 04:03:36 UTC
Using the 2.6.26 kernel from Debian Lenny, I'm NOT experiencing this bug anymore.
Thank you all!
Comment 44 Zhang Rui 2008-09-23 19:00:25 UTC
Good news. :)

Close this bug.

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