Bug 112702 - resume fails on Dell Inspiron 8200
Summary: resume fails on Dell Inspiron 8200
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel   
(Show other bugs)
Version: 1
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-12-29 05:22 UTC by Eric Bourque
Modified: 2007-11-30 22:10 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-29 19:53:29 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Eric Bourque 2003-12-29 05:22:55 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030701

Description of problem:
I'm not sure if this bug should be filed against apmd, or the kernel,
or some other subsystem, but essentially the problem is that after
installing (a fully updated) FC1 on a Dell Inspiron 8200 I can't
resume from suspend. This suspend appears to work correctly, to hard
lock immediately, or to be so unstable that it hard locks within a few
seconds (I type tail /var/log/messages into an open terminal and then
the machine's done before getting any output). Before typing, I can
see that pcmcia services are not restarted since my wireless ethernet
card doesn't light up.

There is nothing unusual written to /var/log/messages, in fact, the
last thing is usually and apmd message saying the machine is
suspended. After that, because I'm forced to reboot the machine, the
restart is the next thing in the log.

For comparison, this works perfectly well on the same laptop running
RH 9 out of the box.

A related bug may be bug 112674, although I tried installing a vanilla
2.4.23, and still had the same problems.

ACPI is not enabled on the kernel command line, and acpid is not running.

Any help greatly appreciated. Not being able to resume or suspend is a
showstopper for me on a laptop.

Version-Release number of selected component (if applicable):
Sorry - I don't have that disk in my laptop right now, but it should
be the default installed with FC1 or the most recent update if there
was one.

How reproducible:

Steps to Reproduce:
1. shut the lid on the laptop
2. machines suspends
3. open the lid, machine tries to resume, and freezes

Actual Results:  machine freezes

Expected Results:  normal resume with fully working pcmcia, etc., just
like in RH 9.

Additional info:

Comment 1 Eric Bourque 2003-12-30 05:35:03 UTC
ok - just tried again, and noticed the mouse still moved around but I
couldn't type anything into the open terminal. I changed to the
console, and tried to log in as root, but before getting a password
prompt, I got the message:

hda: lost interrupt

several times, and was able to do nothing after that.

version of apm is apmd-3.0.2-20

Perhaps this is a kernel bug after all?

Comment 2 David Lowe 2004-01-23 20:20:47 UTC
I have a similar problem with the 2.4.22-1.2149.nptl kernel using Dell
Inspiron 4150. The resume from suspend hangs about 10% of the time,
with a hard lockup and blank screen. No useful error messages appear
in the system logs.

Backing off to the 2.4.22-1.2140.nptl kernel fixes the problem for me.
I am using APM (i.e. I have the apmd demon running, not acpid, and
specify acpi=off as a boot parameter)


Comment 3 Alexander Kain 2004-02-09 17:51:13 UTC
Same here. Fully updated FC1 on a Dell Inspiron 8200, using 
2.4.22-1.2149.nptl. I can hear the drive spinning, but the connection
to it seems lost. As long as you are doing things that are in memory,
like switching between workspaces, or typing "ls", it's ok, but on the
first disk-access that task will freeze. "hda: lost interrupt" is
written to the console. As far as I can recall, this has been a
problem will all FC1 kernels thus far. Also, I have tried with apmd
off, as well as disabling AGP on my binary nvidia driver. The problem
still occurs. Next, I am considering turing of DMA for hda and see if
that fixes it.

Comment 4 Alexander Kain 2004-03-11 00:05:33 UTC
It seems that I have found a workaround... Try the following:

When the system resumes, it seems to come up and be ready for work,
but actually it is NOT (hypothesis). After about 10 seconds of just
sitting there, the hard drive will suddenly do some accessing, and
then it's safe to do whatever. So, perhaps the problem is that some
components having to do with disk access are not resuming as quickly
as the rest of the system. If I ask the system to do something in this
partially resumed state that requires disk access, it freezes.

Please report if this works for you.

Comment 5 Eric Bourque 2004-03-11 06:55:25 UTC
This does work for me. Moreover, after trying to resume this way a few
times, I could no longer get the machine to crash, as if there was
something which needed to happen correctly once, and then it wouldn't
fail after.

I even tried rebooting and then doing a suspend/resume cycle without
waiting (as I normally would), and I got a new message on the console:

hda: lost interrupt
hda: DMA interrupt recovery

and then the machine became useable again!

I should note that between my original post, and now, I have applied
all the core updates.

Comment 6 David Lawrence 2004-09-29 19:53:29 UTC
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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