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
prev 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