Bug 18840 – hdparm wakeup in apmscript broken

Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.

Bug 18840 - hdparm wakeup in apmscript broken

Summary:	hdparm wakeup in apmscript broken

Status:	CLOSED NOTABUG

Aliases:	None

Product:	Red Hat Linux
Classification:	Retired
Component:	apmd (Show other bugs)
Sub Component:
Version:	7.0
Hardware:	i386 Linux

Priority	medium Severity medium
Target Milestone:	---
Target Release:	---
Assigned To:	Bernhard Rosenkraenzer
QA Contact:	Aaron Brown
Docs Contact:

URL:
Whiteboard:
Keywords:

Depends On:
Blocks:
	Show dependency tree / graph

Reported:	2000-10-10 14:43 EDT by manishv
Modified:	2007-04-18 12:29 EDT (History)
CC List:	0 users

See Also:
Fixed In Version:
Doc Type:	Bug Fix
Doc Text:
Story Points:	---
Clone Of:
Environment:
Last Closed:	2000-10-10 14:43:38 EDT
Type:	---
Regression:	---
Mount Type:	---
Documentation:	---
CRM:
Verified Versions:
Category:	---
oVirt Team:	---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---

Attachments	(Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

Groups: None (edit)

Description manishv 2000-10-10 14:43:33 EDT

My laptop does not always correctly wake up from a suspend.  I have a
thinkpad i sereis 1300 laptop.  I tried to use the hdparm on resume and
standby parameters in the apm configuration but realized that they are
inherently broken.

When apmd detects a resume, it tries to run the apmscript.  However, this
script, along with sh, sed and others are on the sleeping disk!!  Of
course, nothing in this script can possibly fix anything.  The correct
solution might be to create a small ramdisk with apmscript and hdparm in it
at suspend time.  On the other hand, perhaps the kernel can have a flag set
to handle these things via proc.  I haven't tried any of these things to
see if they work, since I suspect a problem with the ide driver and my
bios.

Comment 1 Bernhard Rosenkraenzer 2000-10-10 16:41:37 EDT

The exact same tools are used right before entering suspend, so unless you're
VERY low on memory, they're in the kernel's buffer cache. The disk won't be
accessed.

This has been verified to work on a Gericom 3xC (128 MB RAM) with a very broken
disk controller that actually needs -c0 -d0 after a suspend.

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