linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mel Gorman <mel@csn.ul.ie>
To: Robert Schwebel <r.schwebel@pengutronix.de>
Cc: Juergen Beisert <jbe@pengutronix.de>,
	linux-kernel@vger.kernel.org,
	linux-arm-kernel@lists.arm.linux.org.uk,
	linux-hotplug@vger.kernel.org
Subject: Re: Patch "page-allocator: preserve PFN ordering when __GFP_COLD
Date: Wed, 12 Aug 2009 09:20:34 +0000	[thread overview]
Message-ID: <20090812092034.GA19269@csn.ul.ie> (raw)
In-Reply-To: <20090812074753.GL13320@pengutronix.de>

On Wed, Aug 12, 2009 at 09:47:53AM +0200, Robert Schwebel wrote:
> Hi Jürgen,
> 
> adding the patch author to Cc: ...
> 
> rsc
> 
> On Tue, Aug 11, 2009 at 06:30:02PM +0200, Juergen Beisert wrote:
> > Hi,
> > 
> > I get the following Ooops message when "udevadm" is running on an ARM S3C2440
> > CPU based system:
> > 

This is extremely odd. All that patch is doing is changing what order pages
are returned in to the caller when __GFP_COLD is specified.  valid memory. Does
reverting the patch really make the problem go away?

> > [...]
> > starting udevd...done
> > Unable to handle kernel paging request at virtual address e3540000
> > pgd = c39d4000
> > [e3540000] *pgd\0000000
> > Internal error: Oops: 5 [#1]
> > Modules linked in:
> > CPU: 0    Not tainted  (2.6.31-rc4-00296-ge084b2d-dirty #10)
> > PC is at strlen+0xc/0x20
> > LR is at kobject_get_path+0x24/0xa4

I haven't tackled this sort of bug before but it looks more likely that
there is garbage in the sysfs tree that is being tripped up on.

> > pc : [<c0115338>]    lr : [<c0111f48>]    psr: a0000013
> > sp : c39bdea0  ip : 00000005  fp : c029645b
> > r10: c02e0430  r9 : 00000000  r8 : c3802c60
> > r7 : c001de30  r6 : 000000d0  r5 : 00000001  r4 : c001de30
> > r3 : e3550001  r2 : e3540000  r1 : 000000d0  r0 : e3540000
> > Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
> > Control: c000717f  Table: 339d4000  DAC: 00000015
> > Process udevadm (pid: 325, stack limit = 0xc39bc270)
> > Stack: (0xc39bdea0 to 0xc39be000)
> > dea0: c001de28 00000003 c393d778 c399d000 c3802c60 c014dce0 c029645b c0112200
> > dec0: c393d778 00000000 00000003 c393d780 c399d000 c0112400 00000000 00020001
> > dee0: c0307fdc 00000000 c3950960 c027ddc3 c380cda0 c343b3d4 c3811e60 00000000
> > df00: 00000000 c393d778 00000003 c3960520 c393d780 c02e0470 c3960538 c39bdf88
> > df20: 00019cb0 c014dd80 c382db20 00000000 c3960538 c38ede7c 00000003 c014d464
> > df40: c38ede7c c00bf224 c382db20 00019cb0 c39bdf88 00000004 00000003 c39bc000
> > df60: 00000000 c0080bd8 c343b3d4 00000020 00000000 00000000 c382db20 00000004
> > df80: c0022fa8 c0080d38 00000000 00000000 bead3250 00000000 00026d98 00000003
> > dfa0: bead3250 c0022e00 00026d98 00000003 00000003 00019cb0 00000003 00000000
> > dfc0: 00026d98 00000003 bead3250 00000004 00022a90 bead3678 00019cb0 00019cb0
> > dfe0: 00022a94 bead3250 00018114 400d8f1c 40000010 00000003 00000000 00000000
> > [<c0115338>] (strlen+0xc/0x20) from [<c0111f48>] (kobject_get_path+0x24/0xa4)
> > [<c0111f48>] (kobject_get_path+0x24/0xa4) from [<c014dce0>] (dev_uevent+0x1dc/0x208)
> > [<c014dce0>] (dev_uevent+0x1dc/0x208) from [<c0112400>] (kobject_uevent_env+0x18c/0x3a8)
> > [<c0112400>] (kobject_uevent_env+0x18c/0x3a8) from [<c014dd80>] (store_uevent+0x74/0x88)
> > [<c014dd80>] (store_uevent+0x74/0x88) from [<c014d464>] (dev_attr_store+0x20/0x28)
> > [<c014d464>] (dev_attr_store+0x20/0x28) from [<c00bf224>] (sysfs_write_file+0x104/0x13c)
> > [<c00bf224>] (sysfs_write_file+0x104/0x13c) from [<c0080bd8>] (vfs_write+0xb0/0x15c)
> > [<c0080bd8>] (vfs_write+0xb0/0x15c) from [<c0080d38>] (sys_write+0x40/0x6c)
> > [<c0080d38>] (sys_write+0x40/0x6c) from [<c0022e00>] (ret_fast_syscall+0x0/0x2c)
> > Code: c02dbe78 e1a02000 ea000000 e2800001 (e5d03000)
> > ---[ end trace 4d391449ae70e71a ]---
> > Segmentation fault
> > [...]
> > 
> > This Oops does not occure in v2.6.31-rc4 and occures in v2.6.31-rc5. Bisected
> > to the commit:
> > 
> > e084b2d95e48b31aa45f9c49ffc6cdae8bdb21d4
> > "page-allocator: preserve PFN ordering when __GFP_COLD is set"
> > 
> > But its curious: The same binary kernel still runs without this oops on an ARM
> > S3C2410 CPU.
> > 
> > Regards,
> > Juergen
> > 
> > -- 
> > Pengutronix e.K.                              | Juergen Beisert             |
> > Linux Solutions for Science and Industry      | Phone: +49-8766-939 228     |
> > Vertretung Sued/Muenchen, Germany             | Fax:   +49-5121-206917-5555 |
> > Amtsgericht Hildesheim, HRA 2686              | http://www.pengutronix.de/  |
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at  http://vger.kernel.org/majordomo-info.html
> > Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
> 

-- 
Mel Gorman
Part-time Phd Student                          Linux Technology Center
University of Limerick                         IBM Dublin Software Lab

  reply	other threads:[~2009-08-12  9:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-11 16:30 Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Juergen Beisert
2009-08-12  7:47 ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD Robert Schwebel
2009-08-12  9:20   ` Mel Gorman [this message]
2009-08-12 11:11     ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Juergen Beisert
2009-08-12 13:50       ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD Mel Gorman
2009-08-12 15:35         ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Juergen Beisert
2009-08-12 18:40           ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD Arnaud Faucher
2009-08-13  8:39             ` Mel Gorman
2009-08-13  9:22               ` Patch "page-allocator: preserve PFN ordering when __GFP_COLD is set" fails on my system Juergen Beisert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20090812092034.GA19269@csn.ul.ie \
    --to=mel@csn.ul.ie \
    --cc=jbe@pengutronix.de \
    --cc=linux-arm-kernel@lists.arm.linux.org.uk \
    --cc=linux-hotplug@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=r.schwebel@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).