The reporter had got a "PM: Swap header not found" error at the last phase of
write to swap during swap space validation done after swsusp_write or
checkpoint of the snapshotted pages to swap. Turns out that for swap files, a
last step of specifying resume_offset is required for the sanity check
@brad-figg
Yes we did mail lkml and dri-devel. They had ack'ed it back then and
proposed to resolve it by just resetting the write ring buffer index to
0 on resume to be safe.
But not sure it got submitted upstream as it had asked for confirmation.
I am sure the patch would have worked but I debu
Patch for this bug that also addresses other chipsets affected on
resume.
** Patch added: "Fix for 820746"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/+attachment/2636981/+files/video_820746.patch
--
You received this bug notification because you are a member of Ubuntu
Bugs,
@Mynk: Thanks for your efforts in testing out the patch. I know you spent
sleepless nights to get this verified amidst other preemptions.
Regarding the error log on resume, its a different one altogether. It has
something to do with the fact that the radeon_pcie_gart_enable never really
happend
I was pointed to this by a friend of mine (Mayank Rungta) whom I helped
crack a radeon driver OOPs on suspend: (bug 820746)
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/820746/
For some reason, he wanted me to take a look at this issue as well which
has been inactive for sometime :)
Deta
This is _NOT_ a bug. Hibernate is suspend to disk which in other words
is suspend to swap space. And when you boot with resume= arg.,
it would restore back from swap partition/file.
Its not the same as suspend to ram. In your case, you don't have swap space for
the kernel to checkpoint the memory
Curious guy not knowing much about radeon/video drivers but with a can-
debug approach trying to take a stab at this issue based on the
radeon.ko objdump disassembly provided by the bug reporter who happens
to be my friend : (please try the recommendation suggested at the end of
this report in r600
Just to avoid confusion as rdev->cp.wptr is unsigned, by negative I implied
that it was ~0 or 0xU; when read in r600_cp_resume.
So an increment: add $1, %eax before the OOPs wrapped it back to 0. as EAX or
the ring buffer write pointer index at the time of the panic was shown as 0.
Since
Great news!
Attach your r600.c and I can make a proper patch which you can retest before we
can pitch
for it to be included in the next release.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/820746
T
@Herton : Good point regarding a similar fix in r100.c that I wasn't aware.
I didn't even reproduce this as @mynk (reporter and buddy) reproduced this as I
don't have a hardware with radeon chipset :)
I debugged this with the objdump disassembly and the OOPs information.
Seems to exactly match th
10 matches
Mail list logo
