> > > > The following dropped hunk from Pavel should repair it:
> > >
> > > [cc: list trimmed to spare the uninterested]
> > >
> > > Hmm, there are some oddities here in count_and_copy_data_pages(). It
> > > looks like the CONFIG_HIGHMEM panic() is there because copy_page() is
> > > done without kmapping, and the CONFIG_DISCONTIGMEM panic() is there
> > > because the pgdat list etc. are not walked according to VM
> > > conventions.
> >
> > How much memory is needed for HIGHMEM to be neccessary? Is it 1GB? If
> > so, I can well imagine 1GB laptop....
>
> Depends on the arch & other matters. 768Mb on PPC at least, and
> it starting to be common within laptops as well.
I just hope we'll never ever see 64GB i386 laptop...
... We'll probably have to write simpler equivalent of kmap_atomic for
use in suspend_asm.S. It is not really *so* deep magic.
> > This certainly does not work. We'd need to do some deep magic in
> > suspend_asm.S to copy pages back. [Well, deep magic... Same
> > kmap_atomic.] But suspend_asm.S has to guarantee not touching any
> > memory so the change is not quite trivial.
>
> At worst, that could be an arch provided routine. On most PPC32's
> I can then just disable data translation on the MMU and access
> all pages without kmap'ing them. But that's not terribly portable
> and each arch would need different kind of hacking.
It is arch-specific already. What's worse, resume has to be written in
assembly, so you can't simply write kmap_atomic() there. See
arch/i386/kernel/suspend_asm.S.
Pavel
-- Worst form of spam? Adding advertisment signatures ala sourceforge.net. What goes next? Inserting advertisment *into* email? - 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/