Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by "cat /proc/iomem" AFTER suspend-to-disk/resume)
On Dec 21, 2007 3:00 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Fri, 21 Dec 2007 11:06:49 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
>
> > > >
> > > > How do I determine what comes next?
> > > >
> > >
> > > By comparing it with the /proc/iomem from prior to suspending the machine.
> > >
> >
> > The offending information seems to be "9000-9fff : Intel Flush Page"
>
> ah-hah. git-agpgart.patch
>
> > I hope this helps,
>
> It does, thanks.
>
> Dave, a `cat /proc/iomem' crashes after a suspend/resume cycle when it
> reaches the intel_private.ifp_resource record.
>
>
> intel_i915_configure() is called on each resume and it calls
> intel_i9xx_setup_flush() which zeroes out the already-registered `struct
> resource', causing core kernel to oops over a deref of
> parent/sibling/child.
>
> Probably this:
>
> --- a/drivers/char/agp/intel-agp.c~a
> +++ a/drivers/char/agp/intel-agp.c
> @@ -883,8 +883,6 @@ static void intel_i965_g33_setup_chipset
> static void intel_i9xx_setup_flush(void)
> {
> /* setup a resource for this object */
> - memset(_private.ifp_resource, 0,
> sizeof(intel_private.ifp_resource));
> -
> intel_private.ifp_resource.name = "Intel Flush Page";
> intel_private.ifp_resource.flags = IORESOURCE_MEM;
>
> _
>
>
> will be enough to prevent the crash, but I suspect a bit more than that
> will be needed.
>
I tested with the patch applied, and the stackdump did not occur.
However, I notice that the values listed for Intel Page Flush is
changed from the pre-suspend values:
Before the suspend:
9000-9fff : Intel Flush Page
After the resume:
-90001000 : Intel Flush Page
# patch -p1 < akpm.patch
patching file drivers/char/agp/intel-agp.c
Hunk #1 succeeded at 891 (offset 8 lines).
$ cat /proc/iomem
-0009f7ff : System RAM
0009f800-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-7f68 : System RAM
0010-0039e4a7 : Kernel code
0039e4a8-004f0983 : Kernel data
00553000-007ecdfb : Kernel bss
7f69-7f698fff : ACPI Tables
7f699000-7f6f : ACPI Non-volatile Storage
7f70-7fff : reserved
8800-8bff : PCI CardBus #05
8c00-8fff : PCI CardBus #05
-90001000 : Intel Flush Page
c000-cfff : :00:02.0
d000-d1ff : PCI Bus #02
d200-d3ff : PCI Bus #03
d400-d5ff : PCI Bus #02
d400-d4003fff : :02:00.0
d400-d4003fff : sky2
d600-d7ff : PCI Bus #03
d600-d6000fff : :03:00.0
d600-d6000fff : iwl3945
d800-d80f : PCI Bus #04
d800-d8003fff : :04:09.1
d8004000-d8004fff : :04:09.2
d8004000-d8004fff : tifm_7xx1
d8005000-d80057ff : :04:09.1
d8005000-d80057ff : ohci1394
d8006000-d8006fff : :04:09.0
d8006000-d8006fff : yenta_socket
d810-d817 : :00:02.0
d818-d81f : :00:02.1
d820-d823 : :00:02.0
d824-d8243fff : :00:1b.0
d824-d8243fff : ICH HD audio
d8444000-d84443ff : :00:1d.7
d8444000-d84443ff : ehci_hcd
d800-d84447ff : :00:1f.2
d800-d84447ff : ahci
e000-efff : PCI MMCONFIG 0
e000-efff : reserved
fec0-fec0 : reserved
fed0-fed003ff : HPET 0
fed0-fed003ff : reserved
fed14000-fed19fff : reserved
fed1c000-fed8 : reserved
fee0-fee00fff : reserved
ff00- : reserved
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by "cat /proc/iomem" AFTER suspend-to-disk/resume)
On Fri, 21 Dec 2007 11:06:49 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> > >
> > > How do I determine what comes next?
> > >
> >
> > By comparing it with the /proc/iomem from prior to suspending the machine.
> >
>
> The offending information seems to be "9000-9fff : Intel Flush Page"
ah-hah. git-agpgart.patch
> I hope this helps,
It does, thanks.
Dave, a `cat /proc/iomem' crashes after a suspend/resume cycle when it
reaches the intel_private.ifp_resource record.
intel_i915_configure() is called on each resume and it calls
intel_i9xx_setup_flush() which zeroes out the already-registered `struct
resource', causing core kernel to oops over a deref of
parent/sibling/child.
Probably this:
--- a/drivers/char/agp/intel-agp.c~a
+++ a/drivers/char/agp/intel-agp.c
@@ -883,8 +883,6 @@ static void intel_i965_g33_setup_chipset
static void intel_i9xx_setup_flush(void)
{
/* setup a resource for this object */
- memset(_private.ifp_resource, 0,
sizeof(intel_private.ifp_resource));
-
intel_private.ifp_resource.name = "Intel Flush Page";
intel_private.ifp_resource.flags = IORESOURCE_MEM;
_
will be enough to prevent the crash, but I suspect a bit more than that
will be needed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by "cat /proc/iomem" AFTER suspend-to-disk/resume)
On Dec 21, 2007 1:29 AM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > On Fri, 21 Dec 2007 00:58:19 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote: > > > On Dec 20, 2007 12:32 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > > > On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]> > > > 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. > > > > > > > [EMAIL PROTECTED]:~$ cat > test.sh > > while read i > > do > > echo $i > > sleep 1 > > done < /proc/iomem > > ^C > > [EMAIL PROTECTED]:~$ sh test.sh > > -0009f7ff : System RAM > > 0009f800-0009 : reserved > > 000a-000b : Video RAM area > > 000c-000c7fff : Video ROM > > 000f-000f : System ROM > > 0010-7f68 : System RAM > > 0010-0039e4b7 : Kernel code > > 0039e4b8-004f0983 : Kernel data > > 00553000-007ecdfb : Kernel bss > > 7f69-7f698fff : ACPI Tables > > 7f699000-7f6f : ACPI Non-volatile Storage > > 7f70-7fff : reserved > > 8800-8bff : PCI CardBus #05 > > 8c00-8fff : 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. > The offending information seems to be "9000-9fff : Intel Flush Page" [EMAIL PROTECTED]:~# cat /proc/iomem -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-7f68 : System RAM 0010-0039e4b7 : Kernel code 0039e4b8-004f0983 : Kernel data 00553000-007ecdfb : Kernel bss 7f69-7f698fff : ACPI Tables 7f699000-7f6f : ACPI Non-volatile Storage 7f70-7fff : reserved 8800-8bff : PCI CardBus #05 8c00-8fff : PCI CardBus #05 9000-9fff : Intel Flush Page c000-cfff : :00:02.0 d000-d1ff : PCI Bus #02 d200-d3ff : PCI Bus #03 d400-d5ff : PCI Bus #02 d400-d4003fff : :02:00.0 d400-d4003fff : sky2 d600-d7ff : PCI Bus #03 d600-d6000fff : :03:00.0 d600-d6000fff : iwl3945 d800-d80f : PCI Bus #04 d800-d8003fff : :04:09.1 d8004000-d8004fff : :04:09.2 d8004000-d8004fff : tifm_7xx1 d8005000-d80057ff : :04:09.1 d8005000-d80057ff : ohci1394 d8006000-d8006fff : :04:09.0 d8006000-d8006fff : yenta_socket d810-d817 : :00:02.0 d818-d81f : :00:02.1 d820-d823 : :00:02.0 d824-d8243fff : :00:1b.0 d824-d8243fff : ICH HD audio d8444000-d84443ff : :00:1d.7 d8444000-d84443ff : ehci_hcd d800-d84447ff : :00:1f.2 d800-d84447ff : ahci e000-efff : PCI MMCONFIG 0 e000-efff : reserved fec0-fec0 : reserved fed0-fed003ff : HPET 0 fed0-fed003ff : reserved fed14000-fed19fff : reserved fed1c000-fed8 : reserved fee0-fee00fff : reserved ff00- : reserved ~# lspci 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8038 PCI-E Fast
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by cat /proc/iomem AFTER suspend-to-disk/resume)
On Dec 21, 2007 1:29 AM, Andrew Morton [EMAIL PROTECTED] wrote: On Fri, 21 Dec 2007 00:58:19 -0500 Miles Lane [EMAIL PROTECTED] wrote: On Dec 20, 2007 12:32 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane [EMAIL PROTECTED] 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. [EMAIL PROTECTED]:~$ cat test.sh while read i do echo $i sleep 1 done /proc/iomem ^C [EMAIL PROTECTED]:~$ sh test.sh -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-7f68 : System RAM 0010-0039e4b7 : Kernel code 0039e4b8-004f0983 : Kernel data 00553000-007ecdfb : Kernel bss 7f69-7f698fff : ACPI Tables 7f699000-7f6f : ACPI Non-volatile Storage 7f70-7fff : reserved 8800-8bff : PCI CardBus #05 8c00-8fff : 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. The offending information seems to be 9000-9fff : Intel Flush Page [EMAIL PROTECTED]:~# cat /proc/iomem -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-7f68 : System RAM 0010-0039e4b7 : Kernel code 0039e4b8-004f0983 : Kernel data 00553000-007ecdfb : Kernel bss 7f69-7f698fff : ACPI Tables 7f699000-7f6f : ACPI Non-volatile Storage 7f70-7fff : reserved 8800-8bff : PCI CardBus #05 8c00-8fff : PCI CardBus #05 9000-9fff : Intel Flush Page c000-cfff : :00:02.0 d000-d1ff : PCI Bus #02 d200-d3ff : PCI Bus #03 d400-d5ff : PCI Bus #02 d400-d4003fff : :02:00.0 d400-d4003fff : sky2 d600-d7ff : PCI Bus #03 d600-d6000fff : :03:00.0 d600-d6000fff : iwl3945 d800-d80f : PCI Bus #04 d800-d8003fff : :04:09.1 d8004000-d8004fff : :04:09.2 d8004000-d8004fff : tifm_7xx1 d8005000-d80057ff : :04:09.1 d8005000-d80057ff : ohci1394 d8006000-d8006fff : :04:09.0 d8006000-d8006fff : yenta_socket d810-d817 : :00:02.0 d818-d81f : :00:02.1 d820-d823 : :00:02.0 d824-d8243fff : :00:1b.0 d824-d8243fff : ICH HD audio d8444000-d84443ff : :00:1d.7 d8444000-d84443ff : ehci_hcd d800-d84447ff : :00:1f.2 d800-d84447ff : ahci e000-efff : PCI MMCONFIG 0 e000-efff : reserved fec0-fec0 : reserved fed0-fed003ff : HPET 0 fed0-fed003ff : reserved fed14000-fed19fff : reserved fed1c000-fed8 : reserved fee0-fee00fff : reserved ff00- : reserved ~# lspci 00:00.0 Host bridge: Intel Corporation Mobile 945GM/PM/GMS, 943/940GML and 945GT Express Memory Controller Hub (rev 03) 00:02.0 VGA compatible controller: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller (rev 03) 00:02.1 Display controller: Intel Corporation Mobile 945GM/GMS/GME, 943/940GML Express Integrated Graphics Controller (rev 03) 00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02) 00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02) 00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02) 00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02) 00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02) 00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) 00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02) 00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02) 00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2) 00:1f.0 ISA bridge: Intel Corporation 82801GBM (ICH7-M) LPC Interface Bridge (rev 02) 00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801GBM/GHM (ICH7 Family) SATA AHCI Controller (rev 02) 00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02) 02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8038 PCI-E Fast Ethernet Controller (rev 14) 03:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02) 04:09.0 CardBus bridge: Texas
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by cat /proc/iomem AFTER suspend-to-disk/resume)
On Fri, 21 Dec 2007 11:06:49 -0500 Miles Lane [EMAIL PROTECTED] wrote:
How do I determine what comes next?
By comparing it with the /proc/iomem from prior to suspending the machine.
The offending information seems to be 9000-9fff : Intel Flush Page
ah-hah. git-agpgart.patch
I hope this helps,
It does, thanks.
Dave, a `cat /proc/iomem' crashes after a suspend/resume cycle when it
reaches the intel_private.ifp_resource record.
intel_i915_configure() is called on each resume and it calls
intel_i9xx_setup_flush() which zeroes out the already-registered `struct
resource', causing core kernel to oops over a deref of
parent/sibling/child.
Probably this:
--- a/drivers/char/agp/intel-agp.c~a
+++ a/drivers/char/agp/intel-agp.c
@@ -883,8 +883,6 @@ static void intel_i965_g33_setup_chipset
static void intel_i9xx_setup_flush(void)
{
/* setup a resource for this object */
- memset(intel_private.ifp_resource, 0,
sizeof(intel_private.ifp_resource));
-
intel_private.ifp_resource.name = Intel Flush Page;
intel_private.ifp_resource.flags = IORESOURCE_MEM;
_
will be enough to prevent the crash, but I suspect a bit more than that
will be needed.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by cat /proc/iomem AFTER suspend-to-disk/resume)
On Dec 21, 2007 3:00 PM, Andrew Morton [EMAIL PROTECTED] wrote:
On Fri, 21 Dec 2007 11:06:49 -0500 Miles Lane [EMAIL PROTECTED] wrote:
How do I determine what comes next?
By comparing it with the /proc/iomem from prior to suspending the machine.
The offending information seems to be 9000-9fff : Intel Flush Page
ah-hah. git-agpgart.patch
I hope this helps,
It does, thanks.
Dave, a `cat /proc/iomem' crashes after a suspend/resume cycle when it
reaches the intel_private.ifp_resource record.
intel_i915_configure() is called on each resume and it calls
intel_i9xx_setup_flush() which zeroes out the already-registered `struct
resource', causing core kernel to oops over a deref of
parent/sibling/child.
Probably this:
--- a/drivers/char/agp/intel-agp.c~a
+++ a/drivers/char/agp/intel-agp.c
@@ -883,8 +883,6 @@ static void intel_i965_g33_setup_chipset
static void intel_i9xx_setup_flush(void)
{
/* setup a resource for this object */
- memset(intel_private.ifp_resource, 0,
sizeof(intel_private.ifp_resource));
-
intel_private.ifp_resource.name = Intel Flush Page;
intel_private.ifp_resource.flags = IORESOURCE_MEM;
_
will be enough to prevent the crash, but I suspect a bit more than that
will be needed.
I tested with the patch applied, and the stackdump did not occur.
However, I notice that the values listed for Intel Page Flush is
changed from the pre-suspend values:
Before the suspend:
9000-9fff : Intel Flush Page
After the resume:
-90001000 : Intel Flush Page
# patch -p1 akpm.patch
patching file drivers/char/agp/intel-agp.c
Hunk #1 succeeded at 891 (offset 8 lines).
$ cat /proc/iomem
-0009f7ff : System RAM
0009f800-0009 : reserved
000a-000b : Video RAM area
000c-000c7fff : Video ROM
000f-000f : System ROM
0010-7f68 : System RAM
0010-0039e4a7 : Kernel code
0039e4a8-004f0983 : Kernel data
00553000-007ecdfb : Kernel bss
7f69-7f698fff : ACPI Tables
7f699000-7f6f : ACPI Non-volatile Storage
7f70-7fff : reserved
8800-8bff : PCI CardBus #05
8c00-8fff : PCI CardBus #05
-90001000 : Intel Flush Page
c000-cfff : :00:02.0
d000-d1ff : PCI Bus #02
d200-d3ff : PCI Bus #03
d400-d5ff : PCI Bus #02
d400-d4003fff : :02:00.0
d400-d4003fff : sky2
d600-d7ff : PCI Bus #03
d600-d6000fff : :03:00.0
d600-d6000fff : iwl3945
d800-d80f : PCI Bus #04
d800-d8003fff : :04:09.1
d8004000-d8004fff : :04:09.2
d8004000-d8004fff : tifm_7xx1
d8005000-d80057ff : :04:09.1
d8005000-d80057ff : ohci1394
d8006000-d8006fff : :04:09.0
d8006000-d8006fff : yenta_socket
d810-d817 : :00:02.0
d818-d81f : :00:02.1
d820-d823 : :00:02.0
d824-d8243fff : :00:1b.0
d824-d8243fff : ICH HD audio
d8444000-d84443ff : :00:1d.7
d8444000-d84443ff : ehci_hcd
d800-d84447ff : :00:1f.2
d800-d84447ff : ahci
e000-efff : PCI MMCONFIG 0
e000-efff : reserved
fec0-fec0 : reserved
fed0-fed003ff : HPET 0
fed0-fed003ff : reserved
fed14000-fed19fff : reserved
fed1c000-fed8 : reserved
fee0-fee00fff : reserved
ff00- : reserved
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by "cat /proc/iomem" AFTER suspend-to-disk/resume)
On Fri, 21 Dec 2007 00:58:19 -0500 "Miles Lane" <[EMAIL PROTECTED]> wrote: > On Dec 20, 2007 12:32 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]> > > 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. > > > > [EMAIL PROTECTED]:~$ cat > test.sh > while read i > do > echo $i > sleep 1 > done < /proc/iomem > ^C > [EMAIL PROTECTED]:~$ sh test.sh > -0009f7ff : System RAM > 0009f800-0009 : reserved > 000a-000b : Video RAM area > 000c-000c7fff : Video ROM > 000f-000f : System ROM > 0010-7f68 : System RAM > 0010-0039e4b7 : Kernel code > 0039e4b8-004f0983 : Kernel data > 00553000-007ecdfb : Kernel bss > 7f69-7f698fff : ACPI Tables > 7f699000-7f6f : ACPI Non-volatile Storage > 7f70-7fff : reserved > 8800-8bff : PCI CardBus #05 > 8c00-8fff : 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by "cat /proc/iomem" AFTER suspend-to-disk/resume)
Resending... Curse GMail's HTML messages! On Dec 21, 2007 12:58 AM, Miles Lane <[EMAIL PROTECTED]> wrote: > > On Dec 20, 2007 12:32 PM, Andrew Morton <[EMAIL PROTECTED]> wrote: > > > On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]> 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. > > > > [EMAIL PROTECTED]:~$ cat > test.sh > > while read i > do > echo $i > sleep 1 > done < /proc/iomem > ^C > [EMAIL PROTECTED]:~$ sh test.sh > -0009f7ff : System RAM > 0009f800-0009 : reserved > 000a-000b : Video RAM area > 000c-000c7fff : Video ROM > 000f-000f : System ROM > 0010-7f68 : System RAM > 0010-0039e4b7 : Kernel code > 0039e4b8-004f0983 : Kernel data > 00553000-007ecdfb : Kernel bss > 7f69-7f698fff : ACPI Tables > 7f699000-7f6f : ACPI Non-volatile Storage > 7f70-7fff : reserved > 8800-8bff : PCI CardBus #05 > 8c00-8fff : PCI CardBus #05 > Segmentation fault > > How do I determine what comes next? > > Thanks, > Miles > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by "cat /proc/iomem" AFTER suspend-to-disk/resume)
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane <[EMAIL PROTECTED]> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by "cat /proc/iomem" AFTER suspend-to-disk/resume)
On further investigation, "cat /proc/iomem" does not trigger the stack trace until after a suspend-to-disk/resume cycle has occurred. I am removing Ingo and Russell from the TO list (as they are apparently the wrong people) and adding the suspend folks, as suspend is implicated. My .config file can be found here: http://marc.info/?l=linux-kernel=119812903001296=2 Miles Lane wrote: .config attached in order to not trip spam filters. Miles Lane wrote: [ 252.868386] BUG: unable to handle kernel NULL pointer dereference at virtual address 0018 [ 252.868393] printing ip: c012d527 *pde = [ 252.868399] Oops: [#1] SMP [ 252.868403] last sysfs file: /sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda3/stat [ 252.868407] Modules linked in: aes_i586 aes_generic i915 drm rfcomm l2cap bluetooth acpi_cpufreq cpufreq_stats cpufreq_conservative sbs sbshc dm_crypt sbp2 parport_pc lp parport arc4 ecb crypto_blkcipher cryptomgr crypto_algapi snd_hda_intel snd_pcm_oss snd_mixer_oss pcmcia snd_pcm iTCO_wdt iTCO_vendor_support snd_seq_dummy watchdog_core watchdog_dev snd_seq_oss snd_seq_midi tifm_7xx1 snd_rawmidi iwl3945 snd_seq_midi_event rng_core tifm_core mac80211 snd_seq snd_timer snd_seq_device cfg80211 sky2 battery yenta_socket rsrc_nonstatic pcmcia_core ac snd soundcore snd_page_alloc button shpchp pci_hotplug sr_mod cdrom pata_acpi piix ide_core firewire_ohci firewire_core crc_itu_t thermal processor fan [ 252.868469] [ 252.868472] Pid: 7088, comm: head Not tainted (2.6.24-rc5-mm1 #9) [ 252.868476] EIP: 0060:[] EFLAGS: 00010297 CPU: 0 [ 252.868481] EIP is at r_show+0x2a/0x70 [ 252.868483] EAX: EBX: 0001 ECX: c07e3224 EDX: c04bb034 [ 252.868486] ESI: 0008 EDI: ed1f52c0 EBP: f5320f10 ESP: f5320f04 [ 252.868489] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 252.868493] Process head (pid: 7088, ti=f532 task=f532e000 task.ti=f532) [ 252.868495] Stack: c03a6cac ed1f52c0 c07e3224 f5320f50 c0199a7e 2000 bf930807 e1007800 [ 252.868504]ed1f52e0 01d3 000e 000d [ 252.868512]fffb f7d39370 c01998e4 f5320f74 c01af4f5 f5320f9c 2000 bf930807 [ 252.868521] Call Trace: [ 252.868523] [] show_trace_log_lvl+0x12/0x25 [ 252.868529] [] show_stack_log_lvl+0x8a/0x95 [ 252.868534] [] show_registers+0x8c/0x154 [ 252.868538] [] die+0x10e/0x1d2 [ 252.868542] [] do_page_fault+0x52b/0x600 [ 252.868547] [] error_code+0x72/0x78 [ 252.868552] [] seq_read+0x19a/0x26c [ 252.868557] [] proc_reg_read+0x60/0x74 [ 252.868562] [] vfs_read+0xa2/0x11e [ 252.868567] [] sys_read+0x3b/0x60 [ 252.868571] [] sysenter_past_esp+0x6b/0xc1 [ 252.868575] === [ 252.868577] Code: c3 55 89 d1 89 e5 57 89 c7 56 53 8b 50 64 83 7a 0c 00 77 0e 81 7a 08 ff ff 00 00 be 04 00 00 00 76 05 be 08 00 00 00 89 c8 31 db <8b> 40 18 39 d0 74 06 43 83 fb 05 75 f3 8b 41 10 ba 2f 1b 45 c0 [ 252.868623] EIP: [] r_show+0x2a/0x70 SS:ESP 0068:f5320f04 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by cat /proc/iomem AFTER suspend-to-disk/resume)
On further investigation, cat /proc/iomem does not trigger the stack trace until after a suspend-to-disk/resume cycle has occurred. I am removing Ingo and Russell from the TO list (as they are apparently the wrong people) and adding the suspend folks, as suspend is implicated. My .config file can be found here: http://marc.info/?l=linux-kernelm=119812903001296w=2 Miles Lane wrote: .config attached in order to not trip spam filters. Miles Lane wrote: [ 252.868386] BUG: unable to handle kernel NULL pointer dereference at virtual address 0018 [ 252.868393] printing ip: c012d527 *pde = [ 252.868399] Oops: [#1] SMP [ 252.868403] last sysfs file: /sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/sda3/stat [ 252.868407] Modules linked in: aes_i586 aes_generic i915 drm rfcomm l2cap bluetooth acpi_cpufreq cpufreq_stats cpufreq_conservative sbs sbshc dm_crypt sbp2 parport_pc lp parport arc4 ecb crypto_blkcipher cryptomgr crypto_algapi snd_hda_intel snd_pcm_oss snd_mixer_oss pcmcia snd_pcm iTCO_wdt iTCO_vendor_support snd_seq_dummy watchdog_core watchdog_dev snd_seq_oss snd_seq_midi tifm_7xx1 snd_rawmidi iwl3945 snd_seq_midi_event rng_core tifm_core mac80211 snd_seq snd_timer snd_seq_device cfg80211 sky2 battery yenta_socket rsrc_nonstatic pcmcia_core ac snd soundcore snd_page_alloc button shpchp pci_hotplug sr_mod cdrom pata_acpi piix ide_core firewire_ohci firewire_core crc_itu_t thermal processor fan [ 252.868469] [ 252.868472] Pid: 7088, comm: head Not tainted (2.6.24-rc5-mm1 #9) [ 252.868476] EIP: 0060:[c012d527] EFLAGS: 00010297 CPU: 0 [ 252.868481] EIP is at r_show+0x2a/0x70 [ 252.868483] EAX: EBX: 0001 ECX: c07e3224 EDX: c04bb034 [ 252.868486] ESI: 0008 EDI: ed1f52c0 EBP: f5320f10 ESP: f5320f04 [ 252.868489] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 [ 252.868493] Process head (pid: 7088, ti=f532 task=f532e000 task.ti=f532) [ 252.868495] Stack: c03a6cac ed1f52c0 c07e3224 f5320f50 c0199a7e 2000 bf930807 e1007800 [ 252.868504]ed1f52e0 01d3 000e 000d [ 252.868512]fffb f7d39370 c01998e4 f5320f74 c01af4f5 f5320f9c 2000 bf930807 [ 252.868521] Call Trace: [ 252.868523] [c0107d55] show_trace_log_lvl+0x12/0x25 [ 252.868529] [c0107df2] show_stack_log_lvl+0x8a/0x95 [ 252.868534] [c0107e89] show_registers+0x8c/0x154 [ 252.868538] [c010805f] die+0x10e/0x1d2 [ 252.868542] [c039c8c9] do_page_fault+0x52b/0x600 [ 252.868547] [c039af9a] error_code+0x72/0x78 [ 252.868552] [c0199a7e] seq_read+0x19a/0x26c [ 252.868557] [c01af4f5] proc_reg_read+0x60/0x74 [ 252.868562] [c018390d] vfs_read+0xa2/0x11e [ 252.868567] [c0183d02] sys_read+0x3b/0x60 [ 252.868571] [c0106bae] sysenter_past_esp+0x6b/0xc1 [ 252.868575] === [ 252.868577] Code: c3 55 89 d1 89 e5 57 89 c7 56 53 8b 50 64 83 7a 0c 00 77 0e 81 7a 08 ff ff 00 00 be 04 00 00 00 76 05 be 08 00 00 00 89 c8 31 db 8b 40 18 39 d0 74 06 43 83 fb 05 75 f3 8b 41 10 ba 2f 1b 45 c0 [ 252.868623] EIP: [c012d527] r_show+0x2a/0x70 SS:ESP 0068:f5320f04 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by cat /proc/iomem AFTER suspend-to-disk/resume)
On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane [EMAIL PROTECTED] 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by cat /proc/iomem AFTER suspend-to-disk/resume)
Resending... Curse GMail's HTML messages! On Dec 21, 2007 12:58 AM, Miles Lane [EMAIL PROTECTED] wrote: On Dec 20, 2007 12:32 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane [EMAIL PROTECTED] 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. [EMAIL PROTECTED]:~$ cat test.sh while read i do echo $i sleep 1 done /proc/iomem ^C [EMAIL PROTECTED]:~$ sh test.sh -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-7f68 : System RAM 0010-0039e4b7 : Kernel code 0039e4b8-004f0983 : Kernel data 00553000-007ecdfb : Kernel bss 7f69-7f698fff : ACPI Tables 7f699000-7f6f : ACPI Non-volatile Storage 7f70-7fff : reserved 8800-8bff : PCI CardBus #05 8c00-8fff : PCI CardBus #05 Segmentation fault How do I determine what comes next? Thanks, Miles -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: OOPS: 2.6.24-rc5-mm1 -- EIP is at r_show+0x2a/0x70 -- (triggered by cat /proc/iomem AFTER suspend-to-disk/resume)
On Fri, 21 Dec 2007 00:58:19 -0500 Miles Lane [EMAIL PROTECTED] wrote: On Dec 20, 2007 12:32 PM, Andrew Morton [EMAIL PROTECTED] wrote: On Thu, 20 Dec 2007 08:38:03 -0500 Miles Lane [EMAIL PROTECTED] 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. [EMAIL PROTECTED]:~$ cat test.sh while read i do echo $i sleep 1 done /proc/iomem ^C [EMAIL PROTECTED]:~$ sh test.sh -0009f7ff : System RAM 0009f800-0009 : reserved 000a-000b : Video RAM area 000c-000c7fff : Video ROM 000f-000f : System ROM 0010-7f68 : System RAM 0010-0039e4b7 : Kernel code 0039e4b8-004f0983 : Kernel data 00553000-007ecdfb : Kernel bss 7f69-7f698fff : ACPI Tables 7f699000-7f6f : ACPI Non-volatile Storage 7f70-7fff : reserved 8800-8bff : PCI CardBus #05 8c00-8fff : 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. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
