[removed ACPI mailing list from cc:]
On Mon, 03 Mar 2003 15:07:54 +0100, Troels Haugboelle wrote:
> just to add my experience. Maybe it helps. I haven't been able to get
> swsusp working on any 2.4.x kernel until i did an
> hdparm -u1 /dev/hda
> now the strange thing: I tried to turn on the frame buffer device and
> it started chrashing again until i did
> hdparm -u0 /dev/hda
> Before I tried using suspend in 2.5.x with varying success. Now
> everything runs like a charm. Without unmask irq's first the kernel
> dumped
> with either a kernel BUG statement or a fault in ide-disk.c
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.
FWIW I'm using reiserfs, too. Two harddisks, ALi chipset.
Roger
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).
Regards,
Nigel
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
On Tue, 2003-03-04 at 12:39, Roger Luethi wrote:
> On Tue, 04 Mar 2003 11:06:50 +1300, Nigel Cunningham wrote:
> > 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.
I was surprised because I thought you were getting the BUG_ON during
writing the image. Now I see that it's well beforehand.
> 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.
On this topic, would you be willing to test a 2.4 version that supported
highmem? I haven't written support yet, but hope to do it shortly. (I
don't have that much ram myself so you can send me 1GB if you prefer
:>).
> 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).
Hmmm.. strange.
Regards,
Nigel
On Tue, Mar 04, 2003 at 11:06:50AM +1300, Nigel Cunningham wrote:
> 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.
Sure, I get this too:
It now says (copied by hand):
freeing memory: .....................|
(this 'freeing' takes ages, around 30 seconds, while in progress, the disk
light blinks every once in a while, perhaps each time while a dot is being
printed)
syncing disks
suspending devices
suspending device c0418bcc
suspending devices
suspending device c0418bcc
suspending: hda ------------------[ cut here
trace back:
device_susp()
drivers_susp()
do_software_susp()
This happens, I think, from here in kernel/suspend.c:
/* Called from process context */
static int drivers_suspend(void)
{
device_suspend(4, SUSPEND_NOTIFY);
device_suspend(4, SUSPEND_SAVE_STATE);
device_suspend(4, SUSPEND_DISABLE);
...
I think the problem occurs on the second call, SUSPEND_SAVE_STATE:
static int idedisk_suspend(struct device *dev, u32 state, u32 level)
{
ide_drive_t *drive = dev->driver_data;
printk("Suspending device %p\n", dev->driver_data);
/* I hope that every freeze operation from the upper levels have
* already been done...
*/
if (level != SUSPEND_SAVE_STATE)
return 0;
/* set the drive to standby */
printk(KERN_INFO "suspending: %s ", drive->name);
do_idedisk_standby(drive);
drive->blocked = 1;
BUG_ON (HWGROUP(drive)->handler); // <----- this BUGs
return 0;
}
Regards,
bert
--
http://www.PowerDNS.com Open source, database driven DNS Software
http://lartc.org Linux Advanced Routing & Traffic Control HOWTO
http://netherlabs.nl Consulting
On Tue, 04 Mar 2003 13:36:41 +1300, Nigel Cunningham wrote:
> On this topic, would you be willing to test a 2.4 version that supported
> highmem? I haven't written support yet, but hope to do it shortly. (I
> don't have that much ram myself so you can send me 1GB if you prefer
> :>).
If I did so, I wouldn't have enough memory left to boot my workstation <g>.
But when you have a patch highmem support, I can dig out some 2.4 kernel
and give it a try.
Roger