public inbox for linux-kernel@vger.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox