On Dec 20, 2007 12:32 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <miles.lane@xxxxxxxxx> wrote:I still can't reproduce this.
> On further investigation, "cat /proc/iomem" does not trigger the stack
> trace until after a suspend-to-disk/resume cycle has occurred.
Could you please try this?
- cat /proc/iomem
- suspend/resume
- do
while read i
do
echo $i
sleep 1
done < /proc/iomem
then, with luck, we'll be able to work out which /proc/iomem record
immediately precedes the corrupted one.
miles@syntropy:~$ cat > test.sh
while read i
do
echo $i
sleep 1
done < /proc/iomem
^C
miles@syntropy:~$ sh test.sh
00000000-0009f7ff : System RAM
0009f800-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-7f68ffff : System RAM
00100000-0039e4b7 : Kernel code
0039e4b8-004f0983 : Kernel data
00553000-007ecdfb : Kernel bss
7f690000-7f698fff : ACPI Tables
7f699000-7f6fffff : ACPI Non-volatile Storage
7f700000-7fffffff : reserved
88000000-8bffffff : PCI CardBus #05
8c000000-8fffffff : PCI CardBus #05
Segmentation fault
How do I determine what comes next?
Thanks,
Miles
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm