Bug 167528

Summary: suspend to RAM hangs after stopping tasks
Product: [Fedora] Fedora Reporter: cam <camilo>
Component: kernelAssignee: Dave Jones <davej>
Status: CLOSED ERRATA QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: intel-linux-acpi, pfrields, wtogami
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-01 03:14:27 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 165150    

Description cam 2005-09-04 07:34:38 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.9) Gecko/20050620 Firefox/1.0.5

Description of problem:
A laptop that previously suspended reliably, although with noisy error messages, fails to suspend with the latest kernel from yum, kernel-2.6.12-1.1447_FC4

The command used to suspend is triggered within an acpi script although from the shell the behaviour is the same

echo -n mem > /sys/power/state

The xorg display is changed to the suspend vt, and the bar display of tasks being stopped is shown (ending in the pipe) '=====|'. Then the machine hangs hard with no further response to any keys (caps lock, suspend etc).




Version-Release number of selected component (if applicable):
kernel-2.6.12-1.1447_FC4

How reproducible:
Always

Steps to Reproduce:
1. echo -n mem > /sys/power/state
2. observe that the suspend attempt hangs
3. reboot

Actual Results:  Kernel attempted to suspend and after stopping all tasks hung with power, screen on and keyboard unresponsive.

Expected Results:  Normal suspend to RAM, perhaps with some messages on the console.

Additional info:

The previous kernel that suspended successfully was kernel-2.6.12-1.1398_FC4. When it suspended/resumed the output was:

uhci_hcd 0000:00:07.2: remove, state 1
usb usb1: USB disconnect, address 1
uhci_hcd 0000:00:07.2: USB bus 1 deregistered
Linux Tulip driver version 1.1.13 (May 11, 2002)
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
tulip0:  MII transceiver #1 config 1000 status 7849 advertising 01e1.
eth0: ADMtek Comet rev 17 at d89a4c00, 00:D0:59:29:25:31, IRQ 11.
Stopping tasks: =============================================================================================================================|
0000:00:0b.0: tulip_stop_rxtx() failed
Back to C!
Debug: sleeping function called from invalid context at mm/slab.c:2126
in_atomic():0, irqs_disabled():1
 [<c015c376>] kmem_cache_alloc+0x3c/0x49
 [<c0248562>] acpi_pci_link_set+0x3f/0x17f
 [<c02489ac>] irqrouter_resume+0x14/0x28
 [<c0287c5e>] sysdev_resume+0x3d/0xb5
 [<c028bd57>] device_power_up+0x5/0xa
 [<c014a8cb>] suspend_enter+0x44/0x46
 [<c014a859>] suspend_prepare+0x57/0x85
 [<c014a93e>] enter_state+0x49/0x54
 [<c014aa39>] state_store+0x81/0x8f
 [<c014a9b8>] state_store+0x0/0x8f
 [<c01ce194>] subsys_attr_store+0x1b/0x1f
 [<c01ce39d>] flush_write_buffer+0x22/0x28
 [<c01ce3ec>] sysfs_write_file+0x49/0x6e
 [<c01ce3a3>] sysfs_write_file+0x0/0x6e
 [<c017b9e4>] vfs_write+0x9e/0x110
 [<c017bb01>] sys_write+0x41/0x6a
 [<c0103a51>] syscall_call+0x7/0xb
ACPI: PCI Interrupt 0000:00:0b.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt 0000:00:0c.2[A] -> Link [LNKA] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI Interrupt 0000:00:0e.0[A] -> Link [LNKC] -> GSI 10 (level, low) -> IRQ 10
eth1: New link status: Connected (0001)
Restarting tasks... done
ACPI: AC Adapter [ACAD] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Battery Slot [BAT2] (battery absent)
USB Universal Host Controller Interface driver v2.2
SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts
ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 5 (level, low) -> IRQ 5
uhci_hcd 0000:00:07.2: UHCI Host Controller
uhci_hcd 0000:00:07.2: new USB bus registered, assigned bus number 1
uhci_hcd 0000:00:07.2: irq 5, io base 0x0000fcc0
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 2 ports detected
0000:00:0b.0: tulip_stop_rxtx() failed

Note that I use a suspend script that rmmods and kills problematic things:
# sleep script...
service bluetooth stop
#rmmod usb-storage
#rmmod ehci_hcd
#rmmod ohci_hcd
rmmod rfcomm
rmmod l2cap
rmmod hci_usb
rmmod bluetooth
rmmod battery
rmmod ac
rmmod uhci_hcd
rmmod tulip
killall mDNSResponder
killall xscreensaver
hwclock --systohc
echo -n mem > /sys/power/state
mDNSResponder &
(sleep 15 && xscreensaver) &
modprobe ac
modprobe battery
modprobe uhci_hcd
#modprobe ohci_hcd
#modprobe ehci_hcd
modprobe usb-storage
service bluetooth start
hwclock --hctosys
modprobe tulip

Comment 1 Dave Jones 2005-09-30 06:48:08 UTC
Mass update to all FC4 bugs:

An update has been released (2.6.13-1.1526_FC4) which rebases to a new upstream
kernel (2.6.13.2). As there were ~3500 changes upstream between this and the
previous kernel, it's possible your bug has been fixed already.

Please retest with this update, and update this bug if necessary.

Thanks.


Comment 2 cam 2005-10-01 00:24:35 UTC
re-tested with 2.6.13-1.1526_FC4, the new kernel suspends and resumes OK.

There is still a message like before on resume:

Back to C!
Debug: sleeping function called from invalid context at mm/slab.c:2129
in_atomic():0, irqs_disabled():1
 [<c0176913>] kmem_cache_alloc+0x3c/0x4e
 [<c029927a>] acpi_pci_link_set+0x3f/0x17f
 [<c02997e2>] irqrouter_resume+0x1e/0x3c
 [<c02e792d>] sysdev_resume+0x3d/0xb5
 [<c02ec261>] device_power_up+0x5/0xa
 [<c015eaf8>] suspend_enter+0x44/0x46
 [<c015ea5a>] suspend_prepare+0x63/0xbd
 [<c015eb6e>] enter_state+0x49/0x54
 [<c015ec69>] state_store+0x81/0x8f
 [<c015ebe8>] state_store+0x0/0x8f
 [<c020f24a>] subsys_attr_store+0x1e/0x22
 [<c020f454>] flush_write_buffer+0x22/0x28
 [<c020f4a8>] sysfs_write_file+0x4e/0x73
 [<c020f45a>] sysfs_write_file+0x0/0x73
 [<c01a1017>] vfs_write+0xa2/0x15a
 [<c01a117a>] sys_write+0x41/0x6a
 [<c0104465>] syscall_call+0x7/0xb


Comment 3 Dave Jones 2005-10-01 03:14:27 UTC
ok, thats a dupe of 154046
I'll close this one.

thanks