From: Roger Luethi <rl@hellgate.ch>
To: Nigel Cunningham <ncunningham@clear.net.nz>
Cc: Troels Haugboelle <troels_h@astro.ku.dk>,
Pavel Machek <pavel@suse.cz>, bert hubert <ahu@ds9a.nl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [ACPI] Re: S4bios support for 2.5.63
Date: Tue, 4 Mar 2003 00:39:23 +0100 [thread overview]
Message-ID: <20030303233923.GA2234@k3.hellgate.ch> (raw)
In-Reply-To: <1046729210.1850.8.camel@laptop-linux.cunninghams>
On Tue, 04 Mar 2003 11:06:50 +1300, Nigel Cunningham wrote:
> On Tue, 2003-03-04 at 03:30, Roger Luethi wrote:
> > Not sure I follow all of your story but I can confirm that hdparm -u1
> > successfully gets me to the kernel panic due to highmem support still
> > lacking -- i.e. way beyond the BUG_ON() I've been hitting. So it looks
> > like you found a good work-around.
>
> You were hitting the BUG_ON before swsusp was even trying to write the
> image?!! That is interesting! Since count_and_copy is first called post
> driver suspend in the current version, perhaps they are somehow related.
> (This is before swsusp tries to write any of the image to disk).
Huh? After a glance at the code I agree that drivers_suspend happens before
count_and_copy_data_pages, but that means hitting the BUG_ON in
idedisk_suspend before the panic in count_and_copy_data_pages is what I'd
expect. How is that remarkable? ... My current kernel has HIGHMEM enabled,
but previous ones that failed the same way didn't.
Anyway, a few more tests showed that hdparm -u1 helps if I have lots of
memory used (say for fs caches). In two out of two tests, I saw Pavel's
request to send him 1 GB RAM via email.
Suspending directly from a clean boot (after issuing the same hdparm -u1
commands for both disks) I hit the BUG_ON in idedisk_suspend (two out of
two tests, too).
Roger
next prev parent reply other threads:[~2003-03-03 23:29 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-26 21:13 S4bios support for 2.5.63 Pavel Machek
2003-02-27 14:13 ` [ACPI] " Ducrot Bruno
2003-03-04 13:23 ` Pavel Machek
2003-03-04 12:00 ` Ducrot Bruno
2003-03-02 13:31 ` bert hubert
2003-03-02 18:44 ` Nigel Cunningham
2003-03-02 20:21 ` bert hubert
2003-03-02 22:22 ` Alan Cox
2003-03-03 0:39 ` Roger Luethi
2003-03-03 2:08 ` [ACPI] " Nigel Cunningham
2003-03-03 11:31 ` bert hubert
2003-03-03 12:17 ` Roger Luethi
2003-03-03 12:23 ` Pavel Machek
2003-03-03 12:35 ` bert hubert
2003-03-03 12:41 ` Pavel Machek
[not found] ` <1046700474.3782.197.camel@localhost>
2003-03-03 14:30 ` Roger Luethi
2003-03-03 22:06 ` Nigel Cunningham
2003-03-03 23:39 ` Roger Luethi [this message]
2003-03-04 0:36 ` Nigel Cunningham
2003-03-04 10:43 ` Roger Luethi
2003-03-04 9:12 ` bert hubert
2003-03-03 15:11 ` bert hubert
2003-03-03 16:40 ` Alan Cox
2003-03-03 16:23 ` P. Christeas
2003-03-03 16:28 ` bert hubert
2003-03-03 14:25 ` Alan Cox
2003-03-03 12:37 ` Roger Luethi
2003-03-03 14:09 ` Alan Cox
2003-03-03 14:37 ` [ACPI] " Ducrot Bruno
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=20030303233923.GA2234@k3.hellgate.ch \
--to=rl@hellgate.ch \
--cc=ahu@ds9a.nl \
--cc=linux-kernel@vger.kernel.org \
--cc=ncunningham@clear.net.nz \
--cc=pavel@suse.cz \
--cc=troels_h@astro.ku.dk \
/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;
as well as URLs for NNTP newsgroup(s).