LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 12-02-2010, 06:57 AM   #1
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,045

Rep: Reputation: Disabled
Suspend to RAM problems with slack64 13.1


It seems that I have problems with suspend to ram or other power saving features. It works half of the time, the other half hanging or crashing the whole computer. Sometimes it works perfectly, but when it does not work like it should, I get unresponsive system, strange behavior, and just a few minutes ago, I woke up my machine that was sleeping to ram and got a kernel crash (KDE notifications) and dmesg says (minus startup messages that are normal):

Code:
eth0: no IPv6 routers present
tda18271: performing RF tracking filter calibration
tda18271: RF tracking filter calibration complete
hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
vlc[2542]: segfault at 8 ip 00007fefb9aa4959 sp 00007fef9e1399e0 error 4 in libQtCore.so.4.6.2[7fefb991a000+280000]
vlc[2724]: segfault at 8 ip 00007fbd9ca07a6b sp 00007fbd860de328 error 4 in libQtDBus.so.4.6.2[7fbd9c9c2000+78000]
vlc[2779]: segfault at 8 ip 00007fa60d98fa6b sp 00007fa5f81156b8 error 4 in libQtDBus.so.4.6.2[7fa60d94a000+78000]
PM: Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)
lirc_mceusb[2]: suspend
sd 2:0:0:0: [sdb] Synchronizing SCSI cache
sd 2:0:0:0: [sdb] Stopping disk
sd 0:0:0:0: [sda] Synchronizing SCSI cache
sd 0:0:0:0: [sda] Stopping disk
serial 00:08: disabled
parport_pc 00:06: disabled
saa7164 0000:02:00.0: PCI INT A disabled
HDA Intel 0000:01:00.1: PCI INT B disabled
ACPI handle has no context!
[fglrx] IRQ 29 Disabled
[fglrx] Preparing suspend fglrx in kernel.
[fglrx] Suspending fglrx in kernel completed.
[fglrx] Power down the ASIC .
ohci_hcd 0000:00:14.5: PCI INT C disabled
HDA Intel 0000:00:14.2: PCI INT A disabled
pata_atiixp 0000:00:14.1: PCI INT A disabled
ehci_hcd 0000:00:13.2: PCI INT B disabled
ohci_hcd 0000:00:13.1: PCI INT A disabled
ohci_hcd 0000:00:13.0: PCI INT A disabled
ehci_hcd 0000:00:12.2: PCI INT B disabled
ohci_hcd 0000:00:12.1: PCI INT A disabled
ohci_hcd 0000:00:12.0: PCI INT A disabled
ahci 0000:00:11.0: PCI INT A disabled
PM: suspend of devices complete after 1226.818 msecs
r8169 0000:03:00.0: PME# enabled
pcieport 0000:00:0a.0: wake-up capability enabled by ACPI
PM: late suspend of devices complete after 33.022 msecs
ACPI: Preparing to enter system sleep state S3
Disabling non-boot CPUs ...
CPU 1 is now offline
CPU 2 is now offline
CPU 3 is now offline
SMP alternatives: switching to UP code
Extended CMOS year: 2000
Back to C!
PCI-DMA: Resuming GART IOMMU
PCI-DMA: Restoring GART aperture settings
Extended CMOS year: 2000
Enabling non-boot CPUs ...
SMP alternatives: switching to SMP code
Booting Node 0 Processor 1 APIC 0x1
CPU1 is up
Booting Node 0 Processor 2 APIC 0x2
CPU2 is up
Booting Node 0 Processor 3 APIC 0x3
CPU3 is up
ACPI: Waking up from system sleep state S3
pcieport 0000:00:02.0: restoring config space at offset 0x7 (was 0x2000d1d1, writing 0xd1d1)
pcieport 0000:00:02.0: restoring config space at offset 0x1 (was 0x40100107, writing 0x40100507)
pcieport 0000:00:09.0: restoring config space at offset 0x7 (was 0x1f1, writing 0x200001f1)
pcieport 0000:00:09.0: restoring config space at offset 0x1 (was 0x100106, writing 0x100506)
pcieport 0000:00:0a.0: restoring config space at offset 0x1 (was 0x100107, writing 0x100507)
ahci 0000:00:11.0: restoring config space at offset 0xf (was 0x100, writing 0x10a)
ehci_hcd 0000:00:12.2: BAR 0: set to [mem 0xfdeff800-0xfdeff8ff] (PCI address [0xfdeff800-0xfdeff8ff]
ehci_hcd 0000:00:12.2: restoring config space at offset 0x1 (was 0x2b00000, writing 0x2b00112)
ehci_hcd 0000:00:13.2: BAR 0: set to [mem 0xfdeff400-0xfdeff4ff] (PCI address [0xfdeff400-0xfdeff4ff]
ehci_hcd 0000:00:13.2: restoring config space at offset 0x1 (was 0x2b00000, writing 0x2b00112)
pata_atiixp 0000:00:14.1: restoring config space at offset 0x3 (was 0x0, writing 0x4000)
HDA Intel 0000:00:14.2: restoring config space at offset 0xf (was 0x10b, writing 0xb)
HDA Intel 0000:00:14.2: restoring config space at offset 0x1 (was 0x4100006, writing 0x4100002)
fglrx_pci 0000:01:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10a)
fglrx_pci 0000:01:00.0: restoring config space at offset 0xc (was 0x0, writing 0xfdfc0000)
fglrx_pci 0000:01:00.0: restoring config space at offset 0x3 (was 0x800000, writing 0x800010)
fglrx_pci 0000:01:00.0: restoring config space at offset 0x1 (was 0x40100107, writing 0x40100503)
HDA Intel 0000:01:00.1: restoring config space at offset 0xf (was 0x2ff, writing 0x20a)
HDA Intel 0000:01:00.1: restoring config space at offset 0x3 (was 0x800000, writing 0x800010)
HDA Intel 0000:01:00.1: restoring config space at offset 0x1 (was 0x40100107, writing 0x40100103)
saa7164 0000:02:00.0: restoring config space at offset 0xf (was 0x100, writing 0x10b)
saa7164 0000:02:00.0: restoring config space at offset 0x6 (was 0x4, writing 0xfe000004)
saa7164 0000:02:00.0: restoring config space at offset 0x4 (was 0x4, writing 0xfe400004)
saa7164 0000:02:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
saa7164 0000:02:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100103)
r8169 0000:03:00.0: restoring config space at offset 0xf (was 0x1ff, writing 0x10a)
r8169 0000:03:00.0: restoring config space at offset 0xc (was 0x0, writing 0xfebf0000)
r8169 0000:03:00.0: restoring config space at offset 0x8 (was 0xc, writing 0xfcff800c)
r8169 0000:03:00.0: restoring config space at offset 0x6 (was 0xc, writing 0xfcfff00c)
r8169 0000:03:00.0: restoring config space at offset 0x4 (was 0x1, writing 0xe801)
r8169 0000:03:00.0: restoring config space at offset 0x3 (was 0x0, writing 0x10)
r8169 0000:03:00.0: restoring config space at offset 0x1 (was 0x100000, writing 0x100507)
PM: early resume of devices complete after 22.576 msecs
ahci 0000:00:11.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22
ohci_hcd 0000:00:12.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ohci_hcd 0000:00:12.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ehci_hcd 0000:00:12.2: PCI INT B -> GSI 17 (level, low) -> IRQ 17
ohci_hcd 0000:00:13.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ohci_hcd 0000:00:13.1: PCI INT A -> GSI 18 (level, low) -> IRQ 18
ehci_hcd 0000:00:13.2: PCI INT B -> GSI 19 (level, low) -> IRQ 19
pata_atiixp 0000:00:14.1: PCI INT A -> GSI 16 (level, low) -> IRQ 16
HDA Intel 0000:00:14.2: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ohci_hcd 0000:00:14.5: PCI INT C -> GSI 18 (level, low) -> IRQ 18
fglrx_pci 0000:01:00.0: setting latency timer to 64
[fglrx] Power up the ASIC
[fglrx] Preparing resume fglrx in kernel.
[fglrx] Resuming fglrx in kernel completed.
[fglrx] IRQ 29 Enabled
HDA Intel 0000:01:00.1: PCI INT B -> GSI 19 (level, low) -> IRQ 19
HDA Intel 0000:01:00.1: setting latency timer to 64
HDA Intel 0000:01:00.1: irq 28 for MSI/MSI-X
saa7164 0000:02:00.0: PCI INT A -> GSI 17 (level, low) -> IRQ 17
saa7164 0000:02:00.0: setting latency timer to 64
pcieport 0000:00:0a.0: wake-up capability disabled by ACPI
r8169 0000:03:00.0: PME# disabled
parport_pc 00:06: activated
serial 00:08: activated
r8169: eth0: link up
ata4: SATA link down (SStatus 0 SControl 300)
ata5: SATA link down (SStatus 0 SControl 300)
ata6: SATA link down (SStatus 0 SControl 300)
sd 0:0:0:0: [sda] Starting disk
ata2: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/100
ata1.00: configured for UDMA/133
sd 2:0:0:0: [sdb] Starting disk
ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata3.00: configured for UDMA/133
lirc_mceusb[2]: resume
PM: resume of devices complete after 6309.403 msecs
Restarting tasks ... done.
saa7164[0]: Dumping the bus structure:
saa7164[0]:  .type             = 2
saa7164[0]:  .dev->bmmio       = 0xffffc90010c80000
saa7164[0]:  .m_wMaxReqSize    = 0x100
saa7164[0]:  .m_pdwSetRing     = 0xffffc90010c81000
saa7164[0]:  .m_dwSizeSetRing  = 0x1000
saa7164[0]:  .m_pdwGetRing     = 0xffffc90010c82000
saa7164[0]:  .m_dwSizeGetRing  = 0x1000
saa7164[0]:  .m_dwSetReadPos   = 0xf4 (0x3aaba78a)
saa7164[0]:  .m_dwSetWritePos  = 0xf0 (0x4f55bead)
saa7164[0]:  .m_dwGetReadPos   = 0xfc (0xdca79d23)
saa7164[0]:  .m_dwGetWritePos  = 0xf8 (0xeb72a6c2)
------------[ cut here ]------------
kernel BUG at /root/saa7164-stable/v4l/saa7164-bus.c:106!
invalid opcode: 0000 [#1] SMP 
last sysfs file: /sys/devices/platform/vesafb.0/graphics/fb0/state
CPU 3 
Pid: 3465, comm: mythbackend Tainted: P           2.6.33.4 #3 M4A785T-M/System Product Name
RIP: 0010:[<ffffffffa0112802>]  [<ffffffffa0112802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
RSP: 0018:ffff8800ace05b38  EFLAGS: 00010292
RAX: 0000000000000039 RBX: ffff88012c720000 RCX: ffffffff821e6d00
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff821e6bb4
RBP: ffff8800ace05b38 R08: 00000000ffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 000000000000000e R12: ffff88012c720000
R13: 0000000000000000 R14: ffff8800ace05c48 R15: ffff8800ace05db4
FS:  00007f83ca7f4710(0000) GS:ffff8800060c0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2a288d7315 CR3: 0000000105cad000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process mythbackend (pid: 3465, threadinfo ffff8800ace04000, task ffff88009c6c9a80)
Stack:
 ffff8800ace05ba8 ffffffffa0112d5e 00000000ffffffff 0000000000000008
<0> 0000000000013b80 0000000000013b80 ffff8800ace05db4 0000000000013b80
<0> 0000000000013b80 ffff8800ace05c48 ffff88012c720000 0000000000000000
Call Trace:
 [<ffffffffa0112d5e>] saa7164_bus_set+0x3e/0x5e0 [saa7164]
 [<ffffffffa0113efc>] saa7164_cmd_set+0xfc/0x1b0 [saa7164]
 [<ffffffffa011409f>] saa7164_cmd_send+0xef/0x870 [saa7164]
 [<ffffffff81114b3a>] ? __d_lookup+0xaa/0x140
 [<ffffffff81113baf>] ? dput+0xbf/0x190
 [<ffffffff8110ac95>] ? path_to_nameidata+0x25/0x60
 [<ffffffff8110c6e0>] ? link_path_walk+0x610/0xd90
 [<ffffffff8111ac39>] ? mntput_no_expire+0x29/0xf0
 [<ffffffff8111ac39>] ? mntput_no_expire+0x29/0xf0
 [<ffffffffa0114b65>] saa7164_api_transition_port+0x35/0x60 [saa7164]
 [<ffffffffa01107a6>] saa7164_dvb_stop_feed+0xb6/0x260 [saa7164]
 [<ffffffffa00e2905>] dmx_ts_feed_stop_filtering+0x55/0xd0 [dvb_core]
 [<ffffffffa00e0e4a>] dvb_dmxdev_feed_stop+0x9a/0xc0 [dvb_core]
 [<ffffffffa00e1175>] dvb_dmxdev_filter_stop+0xa5/0x100 [dvb_core]
 [<ffffffffa00e1dda>] dvb_demux_release+0x4a/0x210 [dvb_core]
 [<ffffffff81101cc5>] __fput+0xf5/0x210
 [<ffffffff81101e05>] fput+0x25/0x30
 [<ffffffff810fe1ed>] filp_close+0x5d/0x90
 [<ffffffff810fe2b5>] sys_close+0x95/0xe0
 [<ffffffff810028db>] system_call_fastpath+0x16/0x1b
Code: 00 00 83 d0 00 c1 ea 02 89 d2 48 c1 e2 02 48 03 57 30 8b 12 39 97 20 01 00 00 73 13 c7 05 63 a5 00 00 ff ff 00 00 e8 4e fd ff ff <0f> 0b eb fe 85 c0 75 e9 c9 c3 0f 1f 40 00 55 48 89 e5 48 83 ec 
RIP  [<ffffffffa0112802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
 RSP <ffff8800ace05b38>
---[ end trace 763e58341fedc269 ]---
saa7164[0]: i2c_xfer(num = 1)
saa7164[0]: i2c_xfer(num = 1) addr = 0x19  len = 0x3
saa7164[0]: saa7164_api_i2c_write()
saa7164[0]: saa7164_cmd_send(unitid = CX24228/S5H1411-2 (TOP) (38) , command = 0x85, sel = 0x0)
saa7164[0]: saa7164_cmd_send() pcommand_t.seqno = 1
saa7164[0]: saa7164_cmd_send() pcommand_t.size = 2
saa7164[0]: saa7164_bus_set()
saa7164[0]: Dumping the bus structure:
saa7164[0]:  .type             = 2
saa7164[0]:  .dev->bmmio       = 0xffffc90010c80000
saa7164[0]:  .m_wMaxReqSize    = 0x100
saa7164[0]:  .m_pdwSetRing     = 0xffffc90010c81000
saa7164[0]:  .m_dwSizeSetRing  = 0x1000
saa7164[0]:  .m_pdwGetRing     = 0xffffc90010c82000
saa7164[0]:  .m_dwSizeGetRing  = 0x1000
saa7164[0]:  .m_dwSetReadPos   = 0xf4 (0x3aaba78a)
saa7164[0]:  .m_dwSetWritePos  = 0xf0 (0x4f55bead)
saa7164[0]:  .m_dwGetReadPos   = 0xfc (0xdca79d23)
saa7164[0]:  .m_dwGetWritePos  = 0xf8 (0xeb72a6c2)
------------[ cut here ]------------
kernel BUG at /root/saa7164-stable/v4l/saa7164-bus.c:106!
invalid opcode: 0000 [#2] SMP 
last sysfs file: /sys/devices/platform/vesafb.0/graphics/fb0/state
CPU 1 
Pid: 2489, comm: kdvb-ad-1-fe-0 Tainted: P      D    2.6.33.4 #3 M4A785T-M/System Product Name
RIP: 0010:[<ffffffffa0112802>]  [<ffffffffa0112802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
RSP: 0000:ffff880100251890  EFLAGS: 00010286
RAX: 0000000000000039 RBX: ffff88012c720000 RCX: 000000000000001e
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff821e6bb4
RBP: ffff880100251890 R08: 00000000ffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 000000000000000e R12: ffff88012c720000
R13: 0000000000000000 R14: ffff8801002519a0 R15: ffff880100251b2e
FS:  00007f0c82d4d700(0000) GS:ffff880006040000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f0c8291694e CR3: 00000000c4045000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kdvb-ad-1-fe-0 (pid: 2489, threadinfo ffff880100250000, task ffff88010e91a120)
Stack:
 ffff880100251900 ffffffffa0112d5e 0000000000000000 dead000000200200
<0> ffff880100251920 0000000041ee2c0c ffff880100251b2e ffff88012c720000
<0> 0000000000000002 ffff8801002519a0 ffff88012c720000 0000000000000000
Call Trace:
 [<ffffffffa0112d5e>] saa7164_bus_set+0x3e/0x5e0 [saa7164]
 [<ffffffffa0113efc>] saa7164_cmd_set+0xfc/0x1b0 [saa7164]
 [<ffffffffa011409f>] saa7164_cmd_send+0xef/0x870 [saa7164]
 [<ffffffff81046785>] ? __call_console_drivers+0x75/0x90
 [<ffffffff81010000>] ? regset_tls_get+0x30/0x100
 [<ffffffff81046e94>] ? release_console_sem+0x1c4/0x210
 [<ffffffff819ffff3>] ? printk+0x41/0x43
 [<ffffffffa0116028>] saa7164_api_i2c_write+0x118/0x270 [saa7164]
 [<ffffffffa010fcbd>] i2c_xfer+0x6d/0x180 [saa7164]
 [<ffffffffa00006dc>] i2c_transfer+0xac/0x100 [i2c_core]
 [<ffffffffa043c0cd>] s5h1411_writereg+0x5d/0xa0 [s5h1411]
 [<ffffffffa043c3e3>] s5h1411_softreset+0x33/0x70 [s5h1411]
 [<ffffffffa043c465>] s5h1411_set_frontend+0x45/0x2c0 [s5h1411]
 [<ffffffffa00e7089>] dvb_frontend_swzigzag_autotune+0x119/0x270 [dvb_core]
 [<ffffffffa00e809a>] dvb_frontend_swzigzag+0x1ea/0x290 [dvb_core]
 [<ffffffffa00e85a8>] dvb_frontend_thread+0x468/0x770 [dvb_core]
 [<ffffffff81065d40>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa00e8140>] ? dvb_frontend_thread+0x0/0x770 [dvb_core]
 [<ffffffff81065846>] kthread+0x96/0xa0
 [<ffffffff81003694>] kernel_thread_helper+0x4/0x10
 [<ffffffff810657b0>] ? kthread+0x0/0xa0
 [<ffffffff81003690>] ? kernel_thread_helper+0x0/0x10
Code: 00 00 83 d0 00 c1 ea 02 89 d2 48 c1 e2 02 48 03 57 30 8b 12 39 97 20 01 00 00 73 13 c7 05 63 a5 00 00 ff ff 00 00 e8 4e fd ff ff <0f> 0b eb fe 85 c0 75 e9 c9 c3 0f 1f 40 00 55 48 89 e5 48 83 ec 
RIP  [<ffffffffa0112802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
 RSP <ffff880100251890>
---[ end trace 763e58341fedc26a ]---
saa7164[0]: i2c_xfer(num = 2)
saa7164[0]: i2c_xfer(num = 2) addr = 0x19  len = 0x1
saa7164[0]: saa7164_api_i2c_read()
saa7164[0]: saa7164_cmd_send(unitid = CX24228/S5H1411-1 (TOP) (7) , command = 0x85, sel = 0x0)
saa7164[0]: saa7164_cmd_send() pcommand_t.seqno = 2
saa7164[0]: saa7164_cmd_send() pcommand_t.size = 2
saa7164[0]: saa7164_bus_set()
saa7164[0]: Dumping the bus structure:
saa7164[0]:  .type             = 2
saa7164[0]:  .dev->bmmio       = 0xffffc90010c80000
saa7164[0]:  .m_wMaxReqSize    = 0x100
saa7164[0]:  .m_pdwSetRing     = 0xffffc90010c81000
saa7164[0]:  .m_dwSizeSetRing  = 0x1000
saa7164[0]:  .m_pdwGetRing     = 0xffffc90010c82000
saa7164[0]:  .m_dwSizeGetRing  = 0x1000
saa7164[0]:  .m_dwSetReadPos   = 0xf4 (0x3aaba78a)
saa7164[0]:  .m_dwSetWritePos  = 0xf0 (0x4f55bead)
saa7164[0]:  .m_dwGetReadPos   = 0xfc (0xdca79d23)
saa7164[0]:  .m_dwGetWritePos  = 0xf8 (0xeb72a6c2)
------------[ cut here ]------------
kernel BUG at /root/saa7164-stable/v4l/saa7164-bus.c:106!
invalid opcode: 0000 [#3] SMP 
last sysfs file: /sys/devices/system/cpu/sched_mc_power_savings
CPU 2 
Pid: 2479, comm: kdvb-ad-0-fe-0 Tainted: P      D    2.6.33.4 #3 M4A785T-M/System Product Name
RIP: 0010:[<ffffffffa0112802>]  [<ffffffffa0112802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
RSP: 0018:ffff8800c9d95900  EFLAGS: 00010286
RAX: 0000000000000039 RBX: ffff88012c720000 RCX: 000000000000001e
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff821e6bb4
RBP: ffff8800c9d95900 R08: 00000000ffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 000000000000000e R12: ffff88012c720000
R13: 0000000000000000 R14: ffff8800c9d95a10 R15: ffff8800c9d95b9e
FS:  00007f6753026710(0000) GS:ffff880006080000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f8967304000 CR3: 000000011377c000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kdvb-ad-0-fe-0 (pid: 2479, threadinfo ffff8800c9d94000, task ffff88010e91c240)
Stack:
 ffff8800c9d95970 ffffffffa0112d5e ffff8800c9d95930 ffffffff81a016aa
<0> ffff8800c9d95940 000000003b0167fc ffff8800c9d95b9e ffff88012c720000
<0> 0000000000000002 ffff8800c9d95a10 ffff88012c720000 0000000000000000
Call Trace:
 [<ffffffffa0112d5e>] saa7164_bus_set+0x3e/0x5e0 [saa7164]
 [<ffffffff81a016aa>] ? __mutex_unlock_slowpath+0x1a/0x40
 [<ffffffffa0113efc>] saa7164_cmd_set+0xfc/0x1b0 [saa7164]
 [<ffffffffa011409f>] saa7164_cmd_send+0xef/0x870 [saa7164]
 [<ffffffff81046785>] ? __call_console_drivers+0x75/0x90
 [<ffffffff81020000>] ? set_msi_irq_affinity+0x10/0xa0
 [<ffffffff81046e94>] ? release_console_sem+0x1c4/0x210
 [<ffffffff819ffff3>] ? printk+0x41/0x43
 [<ffffffffa01162a4>] saa7164_api_i2c_read+0x124/0x290 [saa7164]
 [<ffffffffa010fd3e>] i2c_xfer+0xee/0x180 [saa7164]
 [<ffffffffa00006dc>] i2c_transfer+0xac/0x100 [i2c_core]
 [<ffffffffa043c7fe>] T.363+0x5e/0x90 [s5h1411]
 [<ffffffffa043ccbd>] s5h1411_read_status+0x12d/0x190 [s5h1411]
 [<ffffffffa00e7f4c>] dvb_frontend_swzigzag+0x9c/0x290 [dvb_core]
 [<ffffffffa00e85a8>] dvb_frontend_thread+0x468/0x770 [dvb_core]
 [<ffffffff81065d40>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa00e8140>] ? dvb_frontend_thread+0x0/0x770 [dvb_core]
 [<ffffffff81065846>] kthread+0x96/0xa0
 [<ffffffff81003694>] kernel_thread_helper+0x4/0x10
 [<ffffffff810657b0>] ? kthread+0x0/0xa0
 [<ffffffff81003690>] ? kernel_thread_helper+0x0/0x10
Code: 00 00 83 d0 00 c1 ea 02 89 d2 48 c1 e2 02 48 03 57 30 8b 12 39 97 20 01 00 00 73 13 c7 05 63 a5 00 00 ff ff 00 00 e8 4e fd ff ff <0f> 0b eb fe 85 c0 75 e9 c9 c3 0f 1f 40 00 55 48 89 e5 48 83 ec 
RIP  [<ffffffffa0112802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
 RSP <ffff8800c9d95900>
---[ end trace 763e58341fedc26b ]---
Is there workarounds or patches or anything to be done to enhance this fundamental feature? Its an HTPC so I need sleeping feature flawlessly.

thanks to all
 
Old 12-03-2010, 03:28 AM   #2
business_kid
LQ Guru
 
Registered: Jan 2006
Location: Ireland
Distribution: Slackware, Slarm64 & Android
Posts: 16,289

Rep: Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322Reputation: 2322
Short answers: you are correct - that is a mess!
If you're building your own kernel, check around and people will advise.
Toshiba, IBM (Thinkpads) and even Dell have manufacturer-specific stuff in the kernel, and much about working with them is online. Not a lot for HP, Acer. What's your box?
I have hp. So I gave up on suspend because consoles came up funny. I had had so much (mainly self made) hassle by then the fight wasn't in me. I put hibernate on the lid button, and haven't looked back.
with acpid running with the -l option, and a tail -f on syslog, you can see the events in /etc/acpi/events being triggered. They are pointing to scripts in /etc/acpi. That way, you can at least grok the scripts, and hack them.
 
Old 12-03-2010, 04:15 PM   #3
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,045

Original Poster
Rep: Reputation: Disabled
many thanks for your reply!

this is not a packaged machine such as an HP or a Dell or toshiba but a custom built using an AMD CPU and a ASUS mobo (M4A785T)...

So if I understand correctly,. building a custom kernel would help?
 
Old 12-03-2010, 04:31 PM   #4
GrapefruiTgirl
LQ Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556
I'm no expert on suspending, but what it looks like to me, is the saa7164 module is a contributor in the problems upon resume. If I were trying to fix that, the first thing I'd do would be test suspend/resume with the saa7164 driver UN-modprobed and see if all is well. Depending on the result of that testing, decide what to do next.

rworkman (Robby Workman) has been posting for testers on occasion for his pm-suspend and/or pm-hibernate tools package for Slackware. Have you tried that (or are you using it now?). Perhaps trying that would lead you somewhere good? I haven't checked these tools out myself, so I have no idea what-all they offer or how they work; however there are a few LQ threads about them where maybe you can learn more.

Also, there's my suspend script, located here, which you might find can make it a little more convenient to test the various phases of a suspend operation, and to unplug modules before suspending (and reinsert them upon resume). I use it reliably many times daily on my Slack64-current box, so it seems fairly bug-free; if you try it and have questions, contact me or post here or in that thread and I'll try to help.

TuxOnIce is a set of kernel patches geared towards improving suspend/hibernation, but I've never used it and would consider it a last resort, since it is kernel patches. I think it's more for laptops too, but you'd need to investigate for yourself to see if I'm right on that, and to see if you'd consider this route anyway.

No other suggestions at the moment. Good luck and keep us posted.
 
Old 12-03-2010, 06:10 PM   #5
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,045

Original Poster
Rep: Reputation: Disabled
Thanks to both of you for replying! Sounds like it is going to get interesting...

Quote:
I'm no expert on suspending, but what it looks like to me, is the saa7164 module is a contributor in the problems upon resume.
Agree 100%. To verify, I tried this:

1-shutdown mythbackend (mythTV & this process is using saa7164)
2-unload tveeprom & saa7164 (saa7164 depends on tveeprom )
3-Perform a suspend to ram
4-resume => no errors in dmesg or any other glitches
5-Load the modules above => no errors loading them, even saa7164 loads fine (dmesg shows good messages like a fresh boot)
6-start mythbackend => it works... (optional step, probably useless..)

However, if I perform the above without unloading the modules, big troubles ahead.

The console where I had started mythbackend seemed to have crashed with tons of garbage. Apparently, this process does not support suspend on RAM very well.

dmesg showed:

Code:
saa7164[0]: Dumping the bus structure:
saa7164[0]:  .type             = 2
saa7164[0]:  .dev->bmmio       = 0xffffc90011080000
saa7164[0]:  .m_wMaxReqSize    = 0x100
saa7164[0]:  .m_pdwSetRing     = 0xffffc90011081000
saa7164[0]:  .m_dwSizeSetRing  = 0x1000
saa7164[0]:  .m_pdwGetRing     = 0xffffc90011082000
saa7164[0]:  .m_dwSizeGetRing  = 0x1000
saa7164[0]:  .m_dwSetReadPos   = 0xf4 (0x3aa3a38a)
saa7164[0]:  .m_dwSetWritePos  = 0xf0 (0xdf55b6ad)
saa7164[0]:  .m_dwGetReadPos   = 0xfc (0x5ca79d03)
saa7164[0]:  .m_dwGetWritePos  = 0xf8 (0xeb7aa6ca)
------------[ cut here ]------------
kernel BUG at /root/saa7164-stable/v4l/saa7164-bus.c:106!
invalid opcode: 0000 [#1] SMP 
last sysfs file: /sys/devices/system/cpu/sched_mc_power_savings
CPU 1 
Pid: 3874, comm: kdvb-ad-1-fe-0 Tainted: P           2.6.33.4 #3 M4A785T-M/System Product Name
RIP: 0010:[<ffffffffa00ca802>]  [<ffffffffa00ca802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
RSP: 0018:ffff8800b25f5900  EFLAGS: 00010286
RAX: 0000000000000039 RBX: ffff8800ac1c8000 RCX: ffffffff821e6d00
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff821e6bb4
RBP: ffff8800b25f5900 R08: 00000000ffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 000000000000000e R12: ffff8800ac1c8000
R13: 0000000000000000 R14: ffff8800b25f5a10 R15: ffff8800b25f5b9e
FS:  00007fcc0fefa710(0000) GS:ffff880006040000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007fcc2e984000 CR3: 000000002ade0000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kdvb-ad-1-fe-0 (pid: 3874, threadinfo ffff8800b25f4000, task ffff88012e60ae60)
Stack:
 ffff8800b25f5970 ffffffffa00cad5e ffff8800b25f5930 ffffffff81a016aa
<0> ffff8800b25f5940 ffff8800ac1c8000 ffff8800b25f5b9e ffffffff81a0168b
<0> ffff8800b25f59c0 ffff8800b25f5a10 ffff8800ac1c8000 0000000000000000
Call Trace:
 [<ffffffffa00cad5e>] saa7164_bus_set+0x3e/0x5e0 [saa7164]
 [<ffffffff81a016aa>] ? __mutex_unlock_slowpath+0x1a/0x40
 [<ffffffff81a0168b>] ? mutex_unlock+0x1b/0x20
 [<ffffffffa00cbefc>] saa7164_cmd_set+0xfc/0x1b0 [saa7164]
 [<ffffffffa00cc09f>] saa7164_cmd_send+0xef/0x870 [saa7164]
 [<ffffffffa00ce088>] ? saa7164_api_i2c_write+0x178/0x270 [saa7164]
 [<ffffffffa00ce2a4>] saa7164_api_i2c_read+0x124/0x290 [saa7164]
 [<ffffffffa00c7d3e>] i2c_xfer+0xee/0x180 [saa7164]
 [<ffffffffa000e6dc>] i2c_transfer+0xac/0x100 [i2c_core]
 [<ffffffffa03997fe>] T.363+0x5e/0x90 [s5h1411]
 [<ffffffffa0399cbd>] s5h1411_read_status+0x12d/0x190 [s5h1411]
 [<ffffffffa0066f4c>] dvb_frontend_swzigzag+0x9c/0x290 [dvb_core]
 [<ffffffffa00675a8>] dvb_frontend_thread+0x468/0x770 [dvb_core]
 [<ffffffff81065d40>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa0067140>] ? dvb_frontend_thread+0x0/0x770 [dvb_core]
 [<ffffffff81065846>] kthread+0x96/0xa0
 [<ffffffff81003694>] kernel_thread_helper+0x4/0x10
 [<ffffffff810657b0>] ? kthread+0x0/0xa0
 [<ffffffff81003690>] ? kernel_thread_helper+0x0/0x10
Code: 00 00 83 d0 00 c1 ea 02 89 d2 48 c1 e2 02 48 03 57 30 8b 12 39 97 20 01 00 00 73 13 c7 05 63 a5 00 00 ff ff 00 00 e8 4e fd ff ff <0f> 0b eb fe 85 c0 75 e9 c9 c3 0f 1f 40 00 55 48 89 e5 48 83 ec 
RIP  [<ffffffffa00ca802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
 RSP <ffff8800b25f5900>
---[ end trace 250adeb921d116a3 ]---
saa7164[0]: i2c_xfer(num = 2)
saa7164[0]: i2c_xfer(num = 2) addr = 0x19  len = 0x1
saa7164[0]: saa7164_api_i2c_read()
saa7164[0]: saa7164_cmd_send(unitid = CX24228/S5H1411-1 (TOP) (7) , command = 0x85, sel = 0x0)
saa7164[0]: saa7164_cmd_send() pcommand_t.seqno = 1
saa7164[0]: saa7164_cmd_send() pcommand_t.size = 2
saa7164[0]: saa7164_bus_set()
saa7164[0]: Dumping the bus structure:
saa7164[0]:  .type             = 2
saa7164[0]:  .dev->bmmio       = 0xffffc90011080000
saa7164[0]:  .m_wMaxReqSize    = 0x100
saa7164[0]:  .m_pdwSetRing     = 0xffffc90011081000
saa7164[0]:  .m_dwSizeSetRing  = 0x1000
saa7164[0]:  .m_pdwGetRing     = 0xffffc90011082000
saa7164[0]:  .m_dwSizeGetRing  = 0x1000
saa7164[0]:  .m_dwSetReadPos   = 0xf4 (0x3aa3a38a)
saa7164[0]:  .m_dwSetWritePos  = 0xf0 (0xdf55b6ad)
saa7164[0]:  .m_dwGetReadPos   = 0xfc (0x5ca79d03)
saa7164[0]:  .m_dwGetWritePos  = 0xf8 (0xeb7aa6ca)
------------[ cut here ]------------
kernel BUG at /root/saa7164-stable/v4l/saa7164-bus.c:106!
invalid opcode: 0000 [#2] SMP 
last sysfs file: /sys/devices/system/cpu/sched_mc_power_savings
CPU 0 
Pid: 3870, comm: kdvb-ad-0-fe-0 Tainted: P      D    2.6.33.4 #3 M4A785T-M/System Product Name
RIP: 0010:[<ffffffffa00ca802>]  [<ffffffffa00ca802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
RSP: 0018:ffff8800ad26d900  EFLAGS: 00010286
RAX: 0000000000000039 RBX: ffff8800ac1c8000 RCX: 000000000000001e
RDX: 0000000000000000 RSI: 0000000000000046 RDI: ffffffff821e6bb4
RBP: ffff8800ad26d900 R08: 00000000ffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 000000000000000e R12: ffff8800ac1c8000
R13: 0000000000000000 R14: ffff8800ad26da10 R15: ffff8800ad26db9e
FS:  00007f23f8810700(0000) GS:ffff880006000000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00007f5b26c4d000 CR3: 000000012965b000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kdvb-ad-0-fe-0 (pid: 3870, threadinfo ffff8800ad26c000, task ffff880121e0ae60)
Stack:
 ffff8800ad26d970 ffffffffa00cad5e ffff8800ad26d930 ffffffff81a016aa
<0> ffff8800ad26d940 000000004d149331 ffff8800ad26db9e ffff8800ac1c8000
<0> 0000000000000002 ffff8800ad26da10 ffff8800ac1c8000 0000000000000000
Call Trace:
 [<ffffffffa00cad5e>] saa7164_bus_set+0x3e/0x5e0 [saa7164]
 [<ffffffff81a016aa>] ? __mutex_unlock_slowpath+0x1a/0x40
 [<ffffffffa00cbefc>] saa7164_cmd_set+0xfc/0x1b0 [saa7164]
 [<ffffffffa00cc09f>] saa7164_cmd_send+0xef/0x870 [saa7164]
 [<ffffffff81046785>] ? __call_console_drivers+0x75/0x90
 [<ffffffff81010000>] ? regset_tls_get+0x30/0x100
 [<ffffffff81046e94>] ? release_console_sem+0x1c4/0x210
 [<ffffffff819ffff3>] ? printk+0x41/0x43
 [<ffffffffa00ce2a4>] saa7164_api_i2c_read+0x124/0x290 [saa7164]
 [<ffffffffa00c7d3e>] i2c_xfer+0xee/0x180 [saa7164]
 [<ffffffffa000e6dc>] i2c_transfer+0xac/0x100 [i2c_core]
 [<ffffffffa03997fe>] T.363+0x5e/0x90 [s5h1411]
 [<ffffffffa0399cbd>] s5h1411_read_status+0x12d/0x190 [s5h1411]
 [<ffffffffa0066f4c>] dvb_frontend_swzigzag+0x9c/0x290 [dvb_core]
 [<ffffffffa00675a8>] dvb_frontend_thread+0x468/0x770 [dvb_core]
 [<ffffffff81065d40>] ? autoremove_wake_function+0x0/0x40
 [<ffffffffa0067140>] ? dvb_frontend_thread+0x0/0x770 [dvb_core]
 [<ffffffff81065846>] kthread+0x96/0xa0
 [<ffffffff81003694>] kernel_thread_helper+0x4/0x10
 [<ffffffff810657b0>] ? kthread+0x0/0xa0
 [<ffffffff81003690>] ? kernel_thread_helper+0x0/0x10
Code: 00 00 83 d0 00 c1 ea 02 89 d2 48 c1 e2 02 48 03 57 30 8b 12 39 97 20 01 00 00 73 13 c7 05 63 a5 00 00 ff ff 00 00 e8 4e fd ff ff <0f> 0b eb fe 85 c0 75 e9 c9 c3 0f 1f 40 00 55 48 89 e5 48 83 ec 
RIP  [<ffffffffa00ca802>] saa7164_bus_verify+0x92/0xa0 [saa7164]
 RSP <ffff8800ad26d900>
---[ end trace 250adeb921d116a4 ]---
proof that saa7164 does not support suspend on ram either.

The strangest thing is KDE showed a popup saying:
Code:
KDE detected that one or more internal sound devices were removed.
Do you want KDE to permanently forget about these devices?
This is the list of devices KDE thinks can be removed:
Output: HD-Audio Generic, ATI HDMI (HDMI Audio Output)
WTF? This is my main audio output device!...

So going forward, I know that I need to unload the Tv tuner modules (tveeprom & saa7164) and kill or somehow shutdown mythtv back end.

I dont use the pm-suspend / pm-hibernate tools from Robby Workman, but I guess trying them wouldnt hurt!? Sure thing is that I will try your script to shutdown/suspend the machine. It seems you put a lot of work on that! Might be worthwhile to try!
 
Old 12-03-2010, 06:18 PM   #6
GrapefruiTgirl
LQ Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556
I can't comment on the KDE thing - I haven't used KDE in some time. I remember that message from waaaay back on occasion, but have no idea what you might do about it. Does the dialog not have a "Don't ask me again!" button?

Quote:
So going forward, I know that I need to unload the Tv tuner modules (tveeprom & saa7164) and kill or somehow shutdown mythtv back end.

I dont use the pm-suspend / pm-hibernate tools from Robby Workman, but I guess trying them wouldnt hurt!? Sure thing is that I will try your script to shutdown/suspend the machine. It seems you put a lot of work on that! Might be worthwhile to try!
Sure, try either method and let us know what's what after that. Depending on how exactly you send your machine to sleep, will influence precisely what you need to configure in order to:
-- get the modules unloaded before suspend
-- go into suspend
-- resume & reinsert the modules in a sane fashion.

Keep us posted.
 
Old 12-03-2010, 06:35 PM   #7
GrapefruiTgirl
LQ Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556
An afterthought also: maybe run command:
Code:
modinfo saa7164
and look at the outputted lines beginning with "parm:" and see if there's anything there about power management, ACPI, or anything related like this. It's unlikely there'll be something there that may help, but worth a look- the "parm:" entries are options which can be passed to the modules when they are inserted.
 
Old 12-03-2010, 07:36 PM   #8
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,045

Original Poster
Rep: Reputation: Disabled
Well I tried your script first. I modified the script to add my "faulty" modules and have this:

unplug_list="ohci_hcd forcedeth hangcheck-timer tveeprom saa7164"
insert_list="ohci_hcd forcedeth tveeprom saa7164"

and called the script with

./suspend_to_ram mem

and the machine went to suspend mode. Upon resuming, I got the same stack of kernel errors... So I am wondering if I modified the script correctly, and therefore are the bad modules unloaded/reloaded like I want?

thanks!
 
Old 12-03-2010, 08:47 PM   #9
GrapefruiTgirl
LQ Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556
Was the Myth-thing backend running at the time, or was that shut down prior to trying this? What I'm getting at, is that if the kernel module is in use (because myth-thing is using it) then it may not be able to un-modprobe until myth-thing is stopped. If this is the case, you might want to add a routine (a function perhaps) to the script to turn off the myth-thing before suspending, and maybe restart it after resume.

Also, note that the suspend script is written such that it should be creating its own log when it runs, capturing everything from kernel.log as well as possibly some other stuff (offhand I cannot remember).

I'll check in here tomorrow or so and see how you're making out; I've no idea how your scripting ability is, but if it isn't good, I'll do what I can to help you incorporate something into the script (if it becomes apparent that it needs to be done) for doing the myth shutdown stuff.

Good luck!
 
Old 12-04-2010, 10:40 AM   #10
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,045

Original Poster
Rep: Reputation: Disabled
Sasha, (yes I got your name in the script ) thanks for replying!

I was tired yesterday and tried to rush the thing more than required and yes I believe the myththing was active when I tried the script.

My scripting abilities are fairly primitive, I am just starting up on scripting... I believe a routine to kill the mythbackend process would be necessary. Can you help me on that? I just tried to kill mythbackend before running the script and all worked perfectly. No errors or kernel crash whatsoever. So I believe the proper modifications to kill & resume the process are necessary.

many thanks!

Last edited by lpallard; 12-04-2010 at 10:45 AM.
 
Old 12-04-2010, 10:51 AM   #11
GrapefruiTgirl
LQ Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556
Yes, I can help!

If nobody has attempted by the time I finish something else I'm doing here (off computer), I will post an updated version of the script, with a function call added somewhere, and inside the function, we will put code required for shutting off the myththing and starting it up again later.

Meanwhile, could you post for me, the exact command(s) you use for stopping and starting the myththing? Thanks.

Give me a couple hours or so and I should have something by then.
 
Old 12-04-2010, 11:50 AM   #12
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,045

Original Poster
Rep: Reputation: Disabled
You are fast! Thanks for helping, very appreciated!

To start mythbackend, I have a script in /etc/rc.d/rc.mythbackend called with the argument "start"... Works flawlessly. To stop I call the same script with "stop" argument.

The script is called to start in the rc.local and stopped in the script rc.local_shutdown...

Code:
#!/bin/sh
# Start/stop/restart mythbackend
#
# Modification done by Benoit Beauchamp, based on rc.mysqld by
#
# Copyright 2003 Patrick J. Volkerding, Concord, CA
# Copyright 2003 Slackware Linux, Inc., Concord, CA
#
# This program comes with NO WARRANTY, to the extent permitted by law.
# You may redistribute copies of this program under the terms of the
# GNU General Public License.
#

# Start mythbackend:
myth_start() {
  if [ -x /usr/local/bin/mythbackend ]; then
    # If there is an old PID file (no mythbackend running), clean it up:
    if [ -r /var/run/mythbackend.pid ]; then
      if ! ps axc | grep mythbackend 1> /dev/null 2> /dev/null ; then
        echo "Cleaning up old /var/run/mythbackend.pid."
        rm -f /var/run/mythbackend.pid
      fi
    fi
    /usr/local/bin/mythbackend -l /var/log/mythbackend.log -v important,general -p /var/run/mythbackend.pid -d
  fi
}

# Stop mythbackend:
myth_stop() {
  # If there is no PID file, ignore this request...
  if [ -r /var/run/mythbackend.pid ]; then
    killall mythbackend
  fi
}

# Restart mythbackend:
myth_restart() {
  myth_stop
  myth_start
}

case "$1" in
'start')
  myth_start
  ;;
'stop')
  myth_stop
  ;;
'restart')
  myth_restart
  ;;
*)
  echo "usage $0 start|stop|restart"
esac
 
Old 12-04-2010, 12:13 PM   #13
GrapefruiTgirl
LQ Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556
added function for running external commands before/after suspend

Good timing! I don't actually need that script body, I just needed to know the command to run or the name of it - which I now do, thanks to your above post.

So, I just finished adding a function call to the suspend script, and have put inside it a call to your rc script above; if I have not made any typos, you should be able to run the below script as-is (though please put your module names back in, and any other personal changes you have made in your version) and it should take care of the mythTV problem.

Version 1.16, updated Dec 04 2010:
Oh, by the way, stuff I have added in this version that is related to the function call, is highlighted in red text;
Code:
#!/bin/sh
# Release version: 1.16 (Dec 04/2010)
# /usr/bin/s2 -- offers some flexibility when locking/suspending your desktop.
# Does not use any LRMI or PCI-register weirdness. This script is intended
# for machines with non-crappy BIOSes and working ACPI implementations.

# Copyright (C) <2009,2010> <Sasha Alexandr> <crawlingwithsnakes at hush dot com>
#
#    This program is free software: you can redistribute it and/or modify
#    it under the terms of the GNU General Public License as published by
#    the Free Software Foundation, either version 3 of the License, or
#    (at your option) any later version.
#
#    This program is distributed in the hope that it will be useful,
#    but WITHOUT ANY WARRANTY; without even the implied warranty of
#    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#    GNU General Public License for more details.
#
#    You should have received a copy of the GNU General Public License
#    along with this program.  If not, see <http://www.gnu.org/licenses/>.

# Testing done on: Slackware 11.0 - kernel 2.6.30
# Testing done on: Slack64-current  kernel=2.6.30.5
# Testing done on: Slack64-13.0     kernel=2.6.32.2
# Testing done on: Slack64-13.1+ (-current) kernel=2.6.35
# Testing hardware: MSI P6N-SLI-FI (MS-7350)
# Intel E2160 Core2 CPU
# nVidia chipset MCP51/430i BIOS 2.7
# Ethernet: Realtek 8211BL using forcedeth driver.
# Video: 2x eVGA eGeForce 7300/7200 PCI-E cards.
# Video: nVidia binary versions 185.18.31 through 256.35 (x86_64)
# DE: KDE 3.5.4 & xscreensaver for locking session.
# DE: XFCE in Slack64-current & xscreensaver for locking session
# DE: 2010: No more KDE - using small window manager now.
#--proposed changes (to do):---------------------------------
#--test 'suspend to disk' support (I don't use it yet)
#------------------------------------------------------------
#--<changelog:>     -----------------------------------------
# v1.01  - adjust 'Usage:' text; tidy some code.
#        - support _list_ of NICs; add logging yes/no option.
#        - divert net-restart output to $console.
# v1.02  - clean up some junk that was outputting to console.
#        - clarify comments & Usage:
#        - adjustable args for net & session-lock.
#        - add a bit more sanity checking.
# v1.03  - fix more ugly junk coming on screen after wake-up.
# v1.04  - kill undead forked process when cancel suspend.
#        - remove one function; put that code elsewhere.
# v1.05  - shorten help-page console output linewrap.
#        - clean code a bit.
# v1.10  - adjust/test for Slack64-current.
#        - clean code more.
#        - rename to /usr/bin/s2
# v1.11  - fixed POSIX compliance for shells other than Bash.
#        - fix console output so it doesn't scroll a mile down screen.
# v1.12  - check if user is root as required; or quit.
# v1.13  - fix 'help is displayed twice' when no args given.
# v1.14  - added code to detect which tty the script is called from
#          and return there upon resume. Thanks GazL & tredegar.
#        - tiny code adjustments.
# v1.15  - Fixed some logic errors for the "in????=??" delay settings areas
#        - which had escaped me previously.
#        - now disowning forked s2's so no crap on console upon resume.
#        - Observation: the code is getting convoluted. Needs a rework.
# v1.16  - Added function for running commands/scripts before suspend and
#          after resume. Example: stop mythTV so we can remove its
#          troublesome kernel modules prior to suspend; restart it on resume
#          after re-inserting modules.
#--</changelog>
#-------------------------------------------------------------
#--<known bugs:>
# IF X is not running, using this script from a VT may result in no video
# after resuming. The machine is NOT hung - X can still be started normally
# (blindly) but the VT's seem to remain unusable. I may need to add some
# vbetool functionality to turn the video back on - or 'they' can fix that.
#--
# FIXED: Upon resume, shell prompt is not quite returned to user. You gotta
# hit enter or whatever. Not sure why this is. If you fix it, let me know :-)
#--</known bugs>
#------------------------------------------------------------

setup () {
#-------------------------------adjustable stuff-------------
# two variables to enable/disable function calls which run an
# external command/tool before+after suspend+resume.
# set them 'yes' or 'no'.
external_before_suspend='yes'
external_after_suspend='yes'
# unplug/reinsert any kernel modules you've determined
# cause problems suspending/resuming on your machine.
# If you use the hangcheck-timer, it MUST be a module and
# it MUST be removed before suspend, reinserted after resume.
# If hangcheck-timer is built static into the kernel, suspend
# will only work once; subsequent suspends will resume
# immediately all by themselves.
unplug_list="ohci_hcd forcedeth hangcheck-timer"
insert_list="ohci_hcd forcedeth" # if empty, unplug list is used
want_to_log_the_process='y' # change to y to log the suspend
# separate multiple NICs below with spaces like 'eth0 eth1'
# NICs using DHCP:
NIC='eth0' # stop this/these before suspending to ram/disk
#------------------------------non-adjustable stuff-----------
suspend2_log=/var/log/suspend2.log
log_pidfile=/var/run/suspend2_logpid
fork_pidfile=/var/run/suspend2_forkpid
pm_debug_exist=/sys/power/pm_test
version='1.16'
#--------------------------------adjustable stuff-------------
# Common paths to stuff - verify/adjust for your system:
kernel_log=/var/log/kernel
modprobe=/sbin/modprobe
hwclock=/sbin/hwclock
tail=/usr/bin/tail
ifconfig=/sbin/ifconfig
net_init_script=/etc/rc.d/rc.inet1
net_init_script_arg='restart'
session_locker=/usr/X11R6/bin/xscreensaver-command
session_locker_arg='-lock'
console=/dev/tty1
#-----pm debug (adjustable if you want to test stuff)---------
 debug_pm_does_exist () {
  # To test/debug your system's suspend abilities, read the kernel
  # documentation about enabling/using CONFIG_PM_DEBUG
  # note: only one line must be uncommented at any time.
  #
  echo none > /sys/power/pm_test # really suspend (default)
  #echo freezer > /sys/power/pm_test # least invasive test
  #echo devices > /sys/power/pm_test # test device susp/resume
  #echo platform > /sys/power/pm_test # only w/suspend to disk
  #echo processors > /sys/power/pm_test # test CPU susp/resume
  #echo core > /sys/power/pm_test # most invasive test
 }
[ -f $pm_debug_exist ] && debug_pm_does_exist
#---------------------------------------------end pm debug-----

} # end setup

# Do not edit below here unless you know what you're doing.
#--------------------------------------------------------------

usage () {
 unset list
  printf "\n s2: a suspend script by Sasha. Version $version (Orig. Dec 2009)\n"

  [ "$1" = 'error' ] && printf " Error: bad, missing, or extra parameter.\n"
  for i in standby mem disk; do
     [ "$(echo $methods | grep -o $i)" ] && eval $i='1' || unset i
  done;
cat << USAGE
 Usage:

 To suspend immediately, just specify the type of suspend you want, and
 optionally the 'lock' option, which locks your desktop session before
 suspending. If you want the machine to automatically suspend at a later time
 then use the additional options. All options are:

 -x | cancel    to abort any pending suspends.
 -l | lock      locks the desktop session before suspending.
 -m | mem       indicates you want 'suspend to ram'
 -d | disk      indicates you want 'suspend to disk'
 -s | standby   indicates you want 'suspend to standby'
  ? | status    shows any current pending suspend operation.
 inmins=mm      will cause a suspend after mm minutes.
 insecs=ss      causes a suspend after ss seconds.
 inhrs=hh       will suspend after hh hours.
 time=HHMM      allows a HHMM format of time-of-day to suspend at.
                NOTE: due to the nature of the "date" system command
                some adjustment is done depending on the time entered.
                If you get unsatisfactory results with the time=HHMM option
                give me an example and description of what happened and I will
                look into it.

 When a suspend instance has been created, you will see on the screen, an
 informational line, showing the actual command used to perform the operation,
 such as:

 Running s2 process: (18203) /bin/sh /usr/bin/s2 fork mem 7200 unlocked 7

 Above, the (18203) is the process ID of the running instance. The remainder of
 the line can be copied as-is, and used to silently start an s2 instance from
 cron or other means.

 As of this writing (version 1.1x), suspend to disk has not been tested by me
 at all. It should work fine - it's reputed to be less troublesome than suspend
 to ram. Standby and suspend to ram both work on my system.
 If you find a bug, i.e. something really dumb/obvious that I missed, point it
 out and I'll fix it.

 If you're so inclined, you can run this from a crontab or an icon/kicker
 button with a command something like: kdesu /path/to/script <args>

 Below shows what suspend methods are currently available on your machine
 and the rest of the possible arguments that s2 accepts:

USAGE

 printf " Usage: $(basename $0) $( [ "$standby" ] && list="standby";
                                       [ "$mem" ] && list="$list mem";
                                      [ "$disk" ] && list="$list disk";
 echo "$list" | sed 's/^[ ]//;s/ /|/g' ) [lock] [inmins=mm | insecs=ss | inhours=hh | time=HHMM]\n"
 printf " Usage: $(basename $0) [cancel] [status] [help]\n\n"
}

external_prog () {
 # In this function, you put code or commands you wish to run before & after
 # the doing the suspend. I have put some sample code here for stopping and
 # restarting mythTV backend:

 case "$1" in
        stop) : ;
                # code here, to run BEFORE suspend.
                /etc/rc.d/rc.mythbackend stop

        ;;
        start) : ;
                # code to run AFTER resume and return to original VT.
                /etc/rc.d/rc.mythbackend start
        ;;
 esac

 # Optional `sleep` command, in case you want to rest before returning from
 # this function.
 # sleep 5
}

logging () {
[ "$want_to_log_the_process" = 'n' ] && return
case $1 in
  start) $tail -f $kernel_log > $suspend2_log &
	 echo $! > $log_pidfile ;;
  stop) if [ -f $log_pidfile ]; then
	deadlog=$(cat $log_pidfile)
	kill $deadlog > /dev/null 2>&1 &
	wait
	fi
	;;
esac;
}

get_jobs () {
 unset fpid running_jobs
 if [ -f $fork_pidfile ]; then
   fpid=$(cat $fork_pidfile); running_jobs=$(ps -p $fpid -o command= )
 fi;
}

message () {
 [ "$1" = 'S' ] && printf "\n$(date) ($(basename $0): Going into $action-sleep now.)\n" > $console
 [ "$1" = 'R' ] && printf "\n$(date) ($(basename $0): Waking up now.)\n" > $console
}

get_current_vt () {
 # Figure out what v/tty we're on when script is called
 # so we can return there upon resume:
 DISPL="$(who am i | grep -oE ':[0-9]+\.' | tr -d .)"
 curr_tty="$(tty | awk '/tty/{gsub ("[a-z/]","");print}')"
 if [ ! "$curr_tty" ]; then
   curr_tty="$(ps -ef | grep /usr/bin/X | \
                        grep -v 'xinit\|grep' | \
                        grep " $DISPL" | \
                        awk '/tty/{print $6}' | tr -d [a-z])"
 fi
 # if we still haven't got a $curr_tty then (until I get a better idea) set it to tty7
 [ ! "$curr_tty" ] && curr_tty='7'
 original_vt=$curr_tty
 #echo "$original_vt" #DEBUG
 #exit #DEBUG ONLY
}

get_current_vt_better () {
 # Thanks to LQ member 'GazL' for this nice efficient replacement for the
 # above function, which gets the current v/tty to return to upon resume:
read user tty month day time display << EOD
$(LANG=C who -m)
EOD

if [ "$display" = "" ] ; then
   where="$tty"
else
   where="${display%.*}"; where="${where#*:}"
   read X_pid < "/tmp/.X${where}-lock"
   where=$(ps h -p "${X_pid}" -o tty)
fi
[ ! "$where" ] && original_vt='7' || original_vt=${where//[a-z]}
 #echo "$original_vt" #DEBUG
 #exit #DEBUG ONLY
}

do_standby () {
 sleep $seconds; sync; sleep 1
 # 'standby' doesn't seem to need module-unplugging or NIC shutdowns..
 chvt 1; message S
 [ "$lock" = 'lock' ] && $session_locker $session_locker_arg >/dev/null 2>&1
 logging start
 echo standby > /sys/power/state

# resuming now:

 $hwclock --hctosys # adjust OS clock
 message R
 logging stop
 chvt $original_vt
 rm -f $log_pidfile $fork_pidfile
} # end of 'do_standby'


do_suspend () {
 sleep $seconds; sync; sleep 1
 # check whether we want to run any external thing/command before proceeding:
 [ "$external_before_suspend" = "yes" ] && external_prog stop
 chvt 1; message S; sleep 2 # (legacy?) change to non-X console to prevent corrupt video
 [ "$lock" = 'lock' ] && $session_locker $session_locker_arg >/dev/null 2>&1
 logging start
 # take down NIC(s) (optional - we restart whole network later anyway)
 interface_list="$(echo $interfaces | sed 's/[ ]/\n/g')"
 for NICs in $(printf "$NIC"); do
   $ifconfig $NICs down
 done;
 # unplug modules known to give problems:
 for mod in $unplug_list; do
   [ "$(lsmod | grep $mod)" ] && $modprobe -r $mod 2>/dev/null
 done;
 echo $action > /sys/power/state

 # Resuming now;

 $hwclock --hctosys # adjust OS clock
 message R
 # reinsert removed modules
 [ ! "$insert_list" ] && insert_list="$unplug_list"
 for mod in $insert_list; do
   $modprobe $mod 2>/dev/null
 done;
 sleep 1 # let things settle
 # Kill any running dhcpcd & restart networking as during a cold boot:
 [ "$(ps ax | grep dhcpcd)" ] && killall -q dhcpcd
 $net_init_script $net_init_script_arg > $console
 chvt $original_vt
 # check if want to run any external thing/command after resuming; I put this
 # _after_ the chvt back to the original VT in case we want to start an
 # X-dependant application but don't want to frig around with $DISPLAY vars
 # and app CLI switches to make it start on the right VT.
 [ "$external_after_suspend" = "yes" ] && external_prog start
 logging stop
 rm -f $log_pidfile $fork_pidfile
} # end of 'do_suspend'

# end of function declarations & setup stuff;
# script entry point:

# check UID
[ $(id -u) != 0 ] && echo "s2 error: you must be UID=0 to run $0" && exit 1

# setup our variables and all that stuff:
setup

if [ "$1" = 'fork' ]; then
 # we're the forked, already-configured instance:
 seconds=$3; lock=$4; original_vt=$5
 case $2 in
   standby)
	do_standby >/dev/null 2>&1 & disown
	echo $! > $fork_pidfile
	exit 0
	;;
   *)
	action=$2
	do_suspend >/dev/null 2>&1 & disown
	echo $! > $fork_pidfile
	exit 0
	;;
 esac;

else # We haven't been set up yet, so deal with cmdline args:

 unset action units; seconds=$((0)); lock='unlocked'
 methods=$(cat /sys/power/state)

if [ $# -eq 0 ]; then
   usage error
   exit 1
fi

 for param in $*; do
  case $param in
    lock|-l) lock='lock' ;;
 standby|-s) [ ! "$action" -a "$(echo $methods | grep -o standby)" ] && action='standby' || usage error ;;
     mem|-m) [ ! "$action" -a "$(echo $methods | grep -o mem)" ] && action='mem' || usage error ;;
    disk|-d) [ ! "$action" -a "$(echo $methods | grep -o disk)" ] && action='disk' || usage error ;;
  status|'?') get_jobs
	   printf "\nRunning s2 process: $( [ "$running_jobs" ] && printf "($fpid) $running_jobs" || printf "None." )\n"
	   exit 0 ;;
  cancel|-x)
	logging stop; get_jobs
	if [ "$fpid" ]; then
	   bloody_die=$(ps ax | grep $(pgrep -P $fpid) | gawk '{/^.[:digit:]+[ ]$/;print $1}')
	   kill $fpid 2>/dev/null &
	   wait
           kill $bloody_die 2>/dev/null &
	   wait
           rm -f $fork_pidfile $log_pidfile
	fi;
	printf "\nAny pending s2 has been canceled.\n"
	exit 0
	;;
 inmins=*) if [ ! "$units" ]; then
               units='mins'; seconds=$(($(echo $param | gawk -F= '{/^inmins=[:digit:]+$/;print $2}')*60))
           else
               usage error; exit 1; fi; ;;
 insecs=*) if [ ! "$units" ]; then
               units='secs'; seconds=$(($(echo $param | gawk -F= '{/^insecs=[:digit:]+$/;print $2}')))
           else
               usage error; exit 1; fi; ;;
inhours=*) if [ ! "$units" ]; then
               units='hrs';  seconds=$(($(echo $param | gawk -F= '{/^inhours=[:digit:]+$/;print $2}')*3600))
           else
               usage error; exit 1; fi; ;;
   time=*)
	   if [ ! "$units" ]; then
                units='time'
	        timegiven="$(echo $param | gawk -F= '{/^time=[:digit:][:digit:][:digit:][:digit:]$/;print $2}')"
	        [ ! "$timegiven" ] && usage error && exit 1
	        unixtimethen=$(($(date -d "$timegiven" +%s)))
	        [ $unixtimethen -lt $(($(date +%s))) ] && unixtimethen=$((unixtimethen+86400))
	        seconds=$((unixtimethen-$(date +%s)))
           else
                usage error; exit 1; fi; ;;

  help|-h|-h*|h*) usage; exit 0 ;;
        *) usage error ; exit 1 ;;
  esac;
 done;


 get_jobs

 if [ "$running_jobs" ]; then
   printf "\nThere's already a suspend2 instance running. Cancel that one first.\n" && exit 1
 fi;

 if [ "$action" -a "$seconds" ]; then

   # If you have trouble with this function 'get_current_vt_better', please let me know,
   # and meanwhile, try the original function 'get_current_vt' instead;
   # Uncomment only one of the 2 lines below:
  # get_current_vt
   get_current_vt_better

   $0 fork $action $seconds $lock $original_vt
   $0 status
   exit 0
 else
   usage error; exit 1
 fi;
fi;

# EOF

Last edited by GrapefruiTgirl; 12-04-2010 at 12:17 PM. Reason: Fixed copy+paste typo, highlighted in RED BOLD about 3/4 way down the script
 
Old 12-04-2010, 12:19 PM   #14
lpallard
Senior Member
 
Registered: Nov 2008
Posts: 1,045

Original Poster
Rep: Reputation: Disabled
You're awesome! Thanks!!

I will try this and post back later on!

thanks!
 
Old 12-04-2010, 12:22 PM   #15
GrapefruiTgirl
LQ Guru
 
Registered: Dec 2006
Location: underground
Distribution: Slackware64
Posts: 7,594

Rep: Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556Reputation: 556
Quote:
Originally Posted by lpallard View Post
You're awesome! Thanks!!

I will try this and post back later on!

thanks!
Not quite awesome, but.. Thanks!

Looking forward to hearing about how this works for you.
 
  


Reply



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Problems after resuming from suspend to ram chessonly Linux - General 1 08-10-2012 07:55 AM
Plz explain Suspend to Disk and Suspend to Ram pkhera_2001 Linux - Newbie 2 02-18-2008 07:23 AM
Suspend to RAM problems broxtor Ubuntu 0 03-31-2007 02:40 AM
How to suspend to ram ? I have problems. gkiagia Linux - Laptop and Netbook 3 09-09-2006 03:45 AM
modem usability problems after starting from "suspend to RAM" pusrob Linux - Networking 1 06-17-2006 02:54 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 12:21 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration