Rafael J. Wysocki wrote:
>> (gdb) l *count_data_pages+0x38
>> 0xc013fbfc is in count_data_pages (kernel/power/snapshot.c:205).
>> 200
>> 201 for_each_zone (zone) {
>> 202 if (is_highmem(zone))
>> 203 continue;
>> 204 m
On Tuesday 29 August 2006 21:38, Jon Escombe wrote:
> Rafael J. Wysocki wrote:
>
> http://www.dresco.co.uk/debug/suspend_e820_patch.jpg
> >>> This one is really strange, like a miscompilation or something.
> >>>
> >>> Could you identify which line of code corresponds to count_data_pages+0x38
Rafael J. Wysocki wrote:
http://www.dresco.co.uk/debug/suspend_e820_patch.jpg
>>> This one is really strange, like a miscompilation or something.
>>>
>>> Could you identify which line of code corresponds to count_data_pages+0x38
>>> (using gdb)?
>> Would be happy to, may need a pointer in the
您好!
我司（广州市南雄贸易有限公司），按季度完税，每月都搁下相当数量的国
税、地税发票。为了避免过多的发票因此作废，特--优惠对外企业、厂家、
个人代理代开！如有需要的请来电话联系！
联系人：陈健生-1 3 8 2 6 4 9 7 4 7 6
[EMAIL PROTECTED]
-
Using Tomcat but need to do more? Need to support web services, security?
Get
On Tuesday 29 August 2006 19:35, Jon Escombe wrote:
> Rafael J. Wysocki wrote:
>
> > Thanks.
> >
> >> http://www.dresco.co.uk/debug/resume_from_disk.jpg
> >
> > This one indicates that page tables are corrupted in the restore loop, just
> > like it used to happen on x86_64 some time ago.
> >
>
Rafael J. Wysocki wrote:
> Thanks.
>
>> http://www.dresco.co.uk/debug/resume_from_disk.jpg
>
> This one indicates that page tables are corrupted in the restore loop, just
> like it used to happen on x86_64 some time ago.
>
> Can you confirm that it doesn't happen if HIGHMEM64 is not set?
Confi
On Monday 28 August 2006 15:16, Jon Escombe wrote:
> Rafael J. Wysocki wrote:
>
> >>> Could you please try the appended patch and see if it changes anything?
> >>>
> >>> Rafael
> >>>
> >> Thanks,
> >>
> >> I'm afraid that patch gives me a BUG at snapshot.c:184 during suspend.
> >
> > Ouch, sorry
