On Wednesday 30 August 2006 20:02, Jon Escombe wrote:
> Rafael J. Wysocki wrote:
>
> > Sorry, I forgot the BUG_ON(), as it's been dropped recently in a patch
> > that's
> > in -mm now. Please just remove the BUG_ON().
>
> Yup, can confirm that removing that line fixes my suspend oops with the
Rafael J. Wysocki wrote:
> Sorry, I forgot the BUG_ON(), as it's been dropped recently in a patch that's
> in -mm now. Please just remove the BUG_ON().
Yup, can confirm that removing that line fixes my suspend oops with the
patch. Unfortunately, the patch doesn't do anything for the HIGHMEM64
On Wednesday 30 August 2006 00:08, Jon Escombe wrote:
> 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))
> >>
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
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
Hi!
> >>> Have dug a little deeper in to my resume problem, and found out that
> >>> it's failing in snapshot.c / copy_data_pages(). BUG_ON(!pbe) is
> >>> invoked on the 2nd iteration, when zone_pfn == 1.
> >> Sorry, may have jumped the gun a little there. After a few more attempts
> >> it's no
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 (not that I know why).
>
>> However, with more testing, I've found that
On Monday 28 August 2006 14:27, Jon Escombe wrote:
> Rafael J. Wysocki wrote:
> > On Thursday 24 August 2006 00:08, Jon Escombe wrote:
> >> Jon Escombe wrote:
> >>> Have dug a little deeper in to my resume problem, and found out that
> >>> it's failing in snapshot.c / copy_data_pages(). BUG_ON(!pb
Rafael J. Wysocki wrote:
> On Thursday 24 August 2006 00:08, Jon Escombe wrote:
>> Jon Escombe wrote:
>>> Have dug a little deeper in to my resume problem, and found out that
>>> it's failing in snapshot.c / copy_data_pages(). BUG_ON(!pbe) is
>>> invoked on the 2nd iteration, when zone_pfn == 1.
On Thursday 24 August 2006 00:08, Jon Escombe wrote:
> Jon Escombe wrote:
> >
> > Have dug a little deeper in to my resume problem, and found out that
> > it's failing in snapshot.c / copy_data_pages(). BUG_ON(!pbe) is
> > invoked on the 2nd iteration, when zone_pfn == 1.
>
> Sorry, may have jum
Hi!
> > Have dug a little deeper in to my resume problem, and found out that
> > it's failing in snapshot.c / copy_data_pages(). BUG_ON(!pbe) is
> > invoked on the 2nd iteration, when zone_pfn == 1.
>
> Sorry, may have jumped the gun a little there. After a few more attempts
> it's not so clea
Jon Escombe wrote:
>
> Have dug a little deeper in to my resume problem, and found out that
> it's failing in snapshot.c / copy_data_pages(). BUG_ON(!pbe) is
> invoked on the 2nd iteration, when zone_pfn == 1.
Sorry, may have jumped the gun a little there. After a few more attempts
it's not so
Jon Escombe wrote:
> Hi, am looking for some pointers to help me with a resume from disk issue.
>
> I have a Lenovo T60 (Core Duo, AHCI). Suspend to ram has been working
> perfectly with the relevant AHCI patches. However suspend to disk always
> fails on resume - it locates and restores the resu
Hi, am looking for some pointers to help me with a resume from disk issue.
I have a Lenovo T60 (Core Duo, AHCI). Suspend to ram has been working
perfectly with the relevant AHCI patches. However suspend to disk always
fails on resume - it locates and restores the resume image, and then
immediat
18 matches
Mail list logo
