Messages in this thread | ![/](/images/icornerl.gif) | | Date | Tue, 4 Mar 2003 00:39:23 +0100 | From | Roger Luethi <> | Subject | Re: [ACPI] Re: S4bios support for 2.5.63 |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| ![\](/images/icornerr.gif) |