All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srivatsa Vaddagiri <vatsa@in.ibm.com>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: linux-kernel@vger.kernel.org, rusty@au1.ibm.com,
	lhcs-devel@lists.sourceforge.net, jun.nakajima@intel.com,
	asit.k.mallick@intel.com, sunil.saxena@intel.com,
	torvalds@osdl.org
Subject: Re: [lhcs-devel] Re: in_atomic doesn't count local_irq_disable?
Date: Fri, 2 Jan 2004 19:30:26 +0530	[thread overview]
Message-ID: <20040102193026.A19698@in.ibm.com> (raw)
In-Reply-To: <20031231190553.B9041@in.ibm.com>; from vatsa@in.ibm.com on Wed, Dec 31, 2003 at 07:05:53PM +0530


On Wed, Dec 31, 2003 at 07:05:53PM +0530, Srivatsa Vaddagiri wrote:
> More debugging reveals that the page fault happens
> always while doing a prefetch. The prefetch is
> present inside list_for_each_entry macros.
> 
> For now I have disabled the x86 prefetch function
> to do nothing.
> 
> The test seems to run fine so far w/o any of the 
> page faults I was experiencing. Will update
> at the end of the overnight run if I hit the problem again.
> 
> Wonder if prefetch has some issues on Intel x86 (P3) SMP systems?
> 

Even after disabling prefetch, I continue
to hit page-faults. 

With prefetch disabled, it _always_
traps because of trying to dereference a NULL pointer in a
list-head.  If I break-in into the debugger, the 
list-head is actually valid (no NULL pointer is present) and 
hence I don't understand why it read a NULL pointer value in
a list head.

With prefetch enabled it traps
because of fetch from arbitrary (random) addresses.

So I am no longer sure if this is a prefetch issue
or/and a hotplug issue. I'm continuing to investigate
and will post any new observation I make here.

FYI, the /proc/cpuinfo output on my SMP system is as below:

processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 10
model name      : Pentium III (Cascades)
stepping        : 1
cpu MHz         : 699.730
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1376.25

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 10
model name      : Pentium III (Cascades)
stepping        : 1
cpu MHz         : 699.726
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1396.73


processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 10
model name      : Pentium III (Cascades)
stepping        : 1
cpu MHz         : 699.726
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1396.73


processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 10
model name      : Pentium III (Cascades)
stepping        : 1
cpu MHz         : 699.726
cache size      : 1024 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 1396.73





-- 


Thanks and Regards,
Srivatsa Vaddagiri,
Linux Technology Center,
IBM Software Labs,
Bangalore, INDIA - 560017

      parent reply	other threads:[~2004-01-02 13:56 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-12-29 15:13 in_atomic doesn't count local_irq_disable? Manfred Spraul
2003-12-30 13:26 ` Srivatsa Vaddagiri
2003-12-31 13:29   ` BUG in x86 do_page_fault? [was Re: in_atomic doesn't count local_irq_disable?] Srivatsa Vaddagiri
2003-12-31 19:08     ` Linus Torvalds
2004-01-04 14:57       ` Pavel Machek
2004-01-04 20:43         ` Linus Torvalds
2004-03-29 15:43         ` Linus Torvalds
2004-03-29 15:42       ` Pavel Machek
2003-12-31 13:35   ` [lhcs-devel] Re: in_atomic doesn't count local_irq_disable? Srivatsa Vaddagiri
2004-01-02  0:52     ` Manfred Spraul
2004-01-02 10:56       ` Srivatsa Vaddagiri
2004-01-02 14:00     ` Srivatsa Vaddagiri [this message]

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=20040102193026.A19698@in.ibm.com \
    --to=vatsa@in.ibm.com \
    --cc=asit.k.mallick@intel.com \
    --cc=jun.nakajima@intel.com \
    --cc=lhcs-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=manfred@colorfullife.com \
    --cc=rusty@au1.ibm.com \
    --cc=sunil.saxena@intel.com \
    --cc=torvalds@osdl.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.