On Fri, 21 Dec 2007 00:58:19 -0500 "Miles Lane" <miles.lane@xxxxxxxxx> wrote: > 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: > > > > > On further investigation, "cat /proc/iomem" does not trigger the stack > > > trace until after a suspend-to-disk/resume cycle has occurred. > > > > I still can't reproduce this. > > > > 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? > By comparing it with the /proc/iomem from prior to suspending the machine. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
