* opps building sparc64 packages
@ 2009-01-02 20:35 Dennis Gilmore
2009-01-20 6:35 ` David Miller
` (3 more replies)
0 siblings, 4 replies; 5+ messages in thread
From: Dennis Gilmore @ 2009-01-02 20:35 UTC (permalink / raw)
To: sparclinux
[-- Attachment #1: Type: text/plain, Size: 4303 bytes --]
trying to build openbabel sparc64
https://sparc.koji.fedoraproject.org/koji/taskinfo?taskID=112540 I got an
opps
sun4v_data_access_exception: ADDR[ffffb83000000008] CTX[16ba] TYPE[0009], going.
\|/ ____ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
lt-atom(22311): Dax [#1]
TSTATE: 0000009911001600 TPC: 00000000004821d8 TNPC: 00000000004821dc Y:
00000000 Not tainted
TPC: <exit_robust_list+0x78/0x10c>
g0: 0000000000000064 g1: 0000000000000000 g2: fff8b83000000008 g3:
00000000000004ac
g4: fffff803e10e9740 g5: fffff803ff392000 g6: fffff8038a094000 g7: 0000000000000001
o0: 00000014000014a4 o1: 000007fefff9d718 o2: 000007fefff9d728 o3:
0000000000000000
o4: 0000000000000000 o5: 0000000000000001 sp: fffff8038a097441 ret_pc:
00000000004666c8
RPC: <do_group_exit+0x8c/0xc4>
l0: fffff803e10e9740 l1: 0000000000000800 l2: 00000014000014a4 l3:
fffff80100612790
l4: 0000000000000000 l5: 0000000000000000 l6: fffff8038a097cf8 l7:
0000000000466700
i0: fffff803e10e9740 i1: 0000000000000001 i2: 0000000000000001 i3:
0000000000000000
i4: 0000000000000000 i5: 0000000000000001 i6: fffff8038a097511 i7:
0000000000465f64
I7: <do_exit+0x1d0/0x8a8>
Caller[0000000000465f64]: do_exit+0x1d0/0x8a8
Caller[00000000004666c8]: do_group_exit+0x8c/0xc4
Caller[00000000004062d4]: linux_sparc_syscall+0x34/0x44
Caller[fffff80100a9203c]: 0xfffff80100a9203c
Instruction DUMP: a8102000 1068001d ac07a7e7 <c6d8a000> 82100000 a0103ff2
80a06000 90008015 92100018
Fixing recursive fault but reboot is needed!
Ive seen something similar building OOo also
22311 ? D 0:00 /builddir/build/BUILD/openbabel-2.2.0b3-20080215-
r2249/test/.libs/lt-atom
the process that should be running ends up in a D state so it is sleeping and
unkillable. the processes hang around until a reboot. any ideas where I
should start looking? this happens on a T1000 and T2000 i've not yet tried on
non-niagara hardware.
Dennis
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: opps building sparc64 packages
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
@ 2009-01-20 6:35 ` David Miller
2009-01-20 6:52 ` David Miller
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2009-01-20 6:35 UTC (permalink / raw)
To: sparclinux
From: Dennis Gilmore <dgilmore@redhat.com>
Date: Fri, 2 Jan 2009 14:35:19 -0600
> trying to build openbabel sparc64
> https://sparc.koji.fedoraproject.org/koji/taskinfo?taskID\x112540 I got an
> opps
>
> sun4v_data_access_exception: ADDR[ffffb83000000008] CTX[16ba] TYPE[0009], going.
...
> lt-atom(22311): Dax [#1]
> TSTATE: 0000009911001600 TPC: 00000000004821d8 TNPC: 00000000004821dc Y:
> 00000000 Not tainted
> TPC: <exit_robust_list+0x78/0x10c>
...
> Ive seen something similar building OOo also
> 22311 ? D 0:00 /builddir/build/BUILD/openbabel-2.2.0b3-20080215-
> r2249/test/.libs/lt-atom
>
> the process that should be running ends up in a D state so it is sleeping and
> unkillable. the processes hang around until a reboot. any ideas where I
> should start looking? this happens on a T1000 and T2000 i've not yet tried on
> non-niagara hardware.
Thanks for this report. I think I know why this happens.
exit_robust_list() just walks the userland linked list of
robust FUTEX objects to release. Since it's userland,
anything can be there, so this can generate all kinds of
exceptions depending upon the address used. Such exceptions
should just silently be handled and cause an abort of the
FUTEX list traversal.
The address in question is in register %g2 as the faulting
instruction is:
ldxa [ %g2 ] %asi, %g3
And register %g2 holds 0xfff8b83000000008 which is inside of
the address space hole on Niagara. Any acccess there is
illegal and will generate a data access exception as we see
here.
The code in sun4v_data_access_exception() needs some logic to properly
handle the case of the kernel doing a userspace access. Currently it
does an OOPS unconditionally when triggered from kernel space, which
is wrong.
I'll fix this up and post a patch.
Thanks again.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: opps building sparc64 packages
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
2009-01-20 6:35 ` David Miller
@ 2009-01-20 6:52 ` David Miller
2009-01-23 17:31 ` Dennis Gilmore
2009-01-24 3:50 ` David Miller
3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2009-01-20 6:52 UTC (permalink / raw)
To: sparclinux
From: David Miller <davem@davemloft.net>
Date: Mon, 19 Jan 2009 22:35:17 -0800 (PST)
> The code in sun4v_data_access_exception() needs some logic to properly
> handle the case of the kernel doing a userspace access. Currently it
> does an OOPS unconditionally when triggered from kernel space, which
> is wrong.
>
> I'll fix this up and post a patch.
Dennis, here is a 2.6.27 based patch that should fix this bug.
sparc64: Fix DAX handling via userspace access from kernel.
If we do a userspace access from kernel mode, and get a
data access exception, we need to check the exception
table just like a normal fault does.
The spitfire DAX handler was doing this, but such logic
was missing from the sun4v DAX code.
Reported-by: Dennis Gilmore <dgilmore@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/arch/sparc64/kernel/traps.c b/arch/sparc64/kernel/traps.c
index c824df1..eb19724 100644
--- a/arch/sparc64/kernel/traps.c
+++ b/arch/sparc64/kernel/traps.c
@@ -1,6 +1,6 @@
/* arch/sparc64/kernel/traps.c
*
- * Copyright (C) 1995,1997,2008 David S. Miller (davem@davemloft.net)
+ * Copyright (C) 1995,1997,2008,2009 David S. Miller (davem@davemloft.net)
* Copyright (C) 1997,1999,2000 Jakub Jelinek (jakub@redhat.com)
*/
@@ -262,6 +262,21 @@ void sun4v_data_access_exception(struct pt_regs *regs, unsigned long addr, unsig
return;
if (regs->tstate & TSTATE_PRIV) {
+ /* Test if this comes from uaccess places. */
+ const struct exception_table_entry *entry;
+
+ entry = search_exception_tables(regs->tpc);
+ if (entry) {
+ /* Ouch, somebody is trying VM hole tricks on us... */
+#ifdef DEBUG_EXCEPTIONS
+ printk("Exception: PC<%016lx> faddr<UNKNOWN>\n", regs->tpc);
+ printk("EX_TABLE: insn<%016lx> fixup<%016lx>\n",
+ regs->tpc, entry->fixup);
+#endif
+ regs->tpc = entry->fixup;
+ regs->tnpc = regs->tpc + 4;
+ return;
+ }
printk("sun4v_data_access_exception: ADDR[%016lx] "
"CTX[%04x] TYPE[%04x], going.\n",
addr, ctx, type);
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: opps building sparc64 packages
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
2009-01-20 6:35 ` David Miller
2009-01-20 6:52 ` David Miller
@ 2009-01-23 17:31 ` Dennis Gilmore
2009-01-24 3:50 ` David Miller
3 siblings, 0 replies; 5+ messages in thread
From: Dennis Gilmore @ 2009-01-23 17:31 UTC (permalink / raw)
To: sparclinux
[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]
On Tuesday 20 January 2009 12:52:28 am David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Mon, 19 Jan 2009 22:35:17 -0800 (PST)
>
> > The code in sun4v_data_access_exception() needs some logic to properly
> > handle the case of the kernel doing a userspace access. Currently it
> > does an OOPS unconditionally when triggered from kernel space, which
> > is wrong.
> >
> > I'll fix this up and post a patch.
Dave,
The patch does fix the issue.
Dennis
> Dennis, here is a 2.6.27 based patch that should fix this bug.
>
> sparc64: Fix DAX handling via userspace access from kernel.
>
> If we do a userspace access from kernel mode, and get a
> data access exception, we need to check the exception
> table just like a normal fault does.
>
> The spitfire DAX handler was doing this, but such logic
> was missing from the sun4v DAX code.
>
> Reported-by: Dennis Gilmore <dgilmore@redhat.com>
> Signed-off-by: David S. Miller <davem@davemloft.net>
>
> diff --git a/arch/sparc64/kernel/traps.c b/arch/sparc64/kernel/traps.c
> index c824df1..eb19724 100644
> --- a/arch/sparc64/kernel/traps.c
> +++ b/arch/sparc64/kernel/traps.c
> @@ -1,6 +1,6 @@
> /* arch/sparc64/kernel/traps.c
> *
> - * Copyright (C) 1995,1997,2008 David S. Miller (davem@davemloft.net)
> + * Copyright (C) 1995,1997,2008,2009 David S. Miller (davem@davemloft.net)
> * Copyright (C) 1997,1999,2000 Jakub Jelinek (jakub@redhat.com)
> */
>
> @@ -262,6 +262,21 @@ void sun4v_data_access_exception(struct pt_regs *regs,
> unsigned long addr, unsig return;
>
> if (regs->tstate & TSTATE_PRIV) {
> + /* Test if this comes from uaccess places. */
> + const struct exception_table_entry *entry;
> +
> + entry = search_exception_tables(regs->tpc);
> + if (entry) {
> + /* Ouch, somebody is trying VM hole tricks on us... */
> +#ifdef DEBUG_EXCEPTIONS
> + printk("Exception: PC<%016lx> faddr<UNKNOWN>\n", regs->tpc);
> + printk("EX_TABLE: insn<%016lx> fixup<%016lx>\n",
> + regs->tpc, entry->fixup);
> +#endif
> + regs->tpc = entry->fixup;
> + regs->tnpc = regs->tpc + 4;
> + return;
> + }
> printk("sun4v_data_access_exception: ADDR[%016lx] "
> "CTX[%04x] TYPE[%04x], going.\n",
> addr, ctx, type);
> --
> To unsubscribe from this list: send the line "unsubscribe sparclinux" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: opps building sparc64 packages
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
` (2 preceding siblings ...)
2009-01-23 17:31 ` Dennis Gilmore
@ 2009-01-24 3:50 ` David Miller
3 siblings, 0 replies; 5+ messages in thread
From: David Miller @ 2009-01-24 3:50 UTC (permalink / raw)
To: sparclinux
From: Dennis Gilmore <dennis@ausil.us>
Date: Fri, 23 Jan 2009 11:31:48 -0600
> On Tuesday 20 January 2009 12:52:28 am David Miller wrote:
> > From: David Miller <davem@davemloft.net>
> > Date: Mon, 19 Jan 2009 22:35:17 -0800 (PST)
> >
> > > The code in sun4v_data_access_exception() needs some logic to properly
> > > handle the case of the kernel doing a userspace access. Currently it
> > > does an OOPS unconditionally when triggered from kernel space, which
> > > is wrong.
> > >
> > > I'll fix this up and post a patch.
> Dave,
>
> The patch does fix the issue.
Thanks a lot for testing.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2009-01-24 3:50 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-01-02 20:35 opps building sparc64 packages Dennis Gilmore
2009-01-20 6:35 ` David Miller
2009-01-20 6:52 ` David Miller
2009-01-23 17:31 ` Dennis Gilmore
2009-01-24 3:50 ` David Miller
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.