From: Brannon Barrett Klopfer <bklopfer@stanford.edu>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: linux-acpi@vger.kernel.org, acpi@linux.intel.com, pavel@suse.cz
Subject: Re: hp dv8000t dead on resume from RAM
Date: Thu, 10 Aug 2006 11:29:54 -0700 [thread overview]
Message-ID: <1155234594.44db7b221296f@webmail.stanford.edu> (raw)
Quoting "Rafael J. Wysocki" <rjw@sisk.pl>:
> On Wednesday 09 August 2006 20:01, Brannon Klopfer wrote:
> > Rafael J. Wysocki wrote:
> > > On Tuesday 08 August 2006 19:15, Brannon Barrett Klopfer wrote:
> > >
> > >> Howdy,
> > >>
> > >> My hp dv8000t (core duo) is completely dead on resume from RAM (no
> caps
> > >> lock, sysrq, netconsole,
> > >> nothing). I've tried a recent (2.6.18-rc4) kernel running almost
> entirely
> > >> naked, so to speak (~990K) -- no support for:
> > >>
> > >> SMP
> > >> preempt
> > >> modules
> > >> networking (+ enet drivers, unless running netconsole)
> > >> USB and SATA (not at same time; rootfs is either usb drive or SATA
> [ext2/3])
> > >> FireWire
> > >> cpufreq
> > >> framebuffer (vga=0)
> > >> audio
> > >> PCMCIA
> > >> IDE (for cdrom)
> > >>
> > >> I've tried both native SATA (ahci) and legacy (ata_piix), but same
> result
> > >> w/both -- completely dead on resume from RAM. Blindly entering
> commands
> > >> does nothing, and running "$suspend ; $shutdown" does nothing
> either. I've
> > >> also tried with and without noapic, and a number of other kernel
> > >> paramaters, but nothing seems to work.
> > >>
> > >> Be more than happy to try out patches, etc. to get this thing
> working.
> > >> Additionally, if someone could point me to that "beep on resume"
> patch,
> > >> that'd be great.
> > >>
> > >
> > > First, please apply the appended patch and try the following:
> > >
> > > (1)
> > > # echo testproc > /sys/power/disk
> > > # echo disk > /sys/power/state
> > >
> > > This should turn off the non-boot CPU, freeze all processes, wait for
> 5
> > > seconds and then thaw the processes and the CPU.
> > >
> > Works fine. FWIW, after applying the patchs (so as to have
> > 2.6.18-rc3-mm2), my internal keyboard didn't work, so I used a USB one.
>
> That is specific to 2.6.18-rc3-mm2 and has nothing to do with the
> suspend.
> There should be a patch for that in hot-fixes.
>
> > It could be my simple .config'ing error, didn't spend much time with
> it,
> > but know that I did use a USB keyboard, hence USB support in the
> kernel.
> > > (2)
> > > # echo test > /sys/power/disk
> > > # echo disk > /sys/power/state
> > >
> > > This should turn off the non-boot CPU, freeze all processes, shrink
> > > memory, suspend all devices, wait for 5 seconds, resume the devices
> etc.
> > > IOW it does everything that's needed for a suspend except for
> actually
> > > suspending.
> > >
> > With *legacy* ata_piix, it works fine, as does a "real"
> suspend-to-disk.
> > It still *will not* resume properly from suspend-to-RAM, with and
> > without noapic.
>
> I think I know what the problem is, but unfortunately I have no patch for
> that. Please look at
> http://www.ussg.iu.edu/hypermail/linux/kernel/0607.3/1566.html
> but the fix discussed there is for AMD/NVidia only.
Hmmm...I did try a kernel with *no* SATA or IDE support, and used a pen
drive for my root; would that rule out that sort of problem, or does the
hardware freak out regardless of whether or not there's a driver for it?
> > Using native ahci and the "test" suspend-to-disk, the system hangs. I
> > did this from init=/bin/bash with vga=794 (so I could see all output),
> > however, at least the last few lines match w/vga=0 (i.e., fb didn't
> > affect problem). The hand-copied (pardon any typos) output is:
>
> Some additional patches are needed for the AHCI suspend, AFAIK.
> I thought they were on the way to the mainline, but it looks like I was
> wrong. See:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0607.2/0885.html
I tried to patch the kernel with the "test/testproc" suspend to disk trick,
but it didn't apply cleanly; I applied it cleanly to 2.6.18-rc4 and then
copied drivers/scsi/ahci.c to the "test/testproc" kernel, but it didn't
seem to make a difference.
Thanks,
Brannon
next reply other threads:[~2006-08-10 18:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-08-10 18:29 Brannon Barrett Klopfer [this message]
2006-08-10 19:19 ` hp dv8000t dead on resume from RAM Rafael J. Wysocki
-- strict thread matches above, loose matches on Subject: below --
2006-08-08 17:15 Brannon Barrett Klopfer
2006-08-08 20:30 ` Rafael J. Wysocki
2006-08-09 18:01 ` Brannon Klopfer
2006-08-09 19:59 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1155234594.44db7b221296f@webmail.stanford.edu \
--to=bklopfer@stanford.edu \
--cc=acpi@linux.intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox