WINING CONFIRMATION

Dear  Winner,

we are please to inform you that 1,000,000.00 ( One Million Pounds ) has been Awarded to you in the ITALIAN
SUPER ENALOTTO ONLINE PROMOTION. Acknowledge the receipt of this mail with the details below to Mr.
Giorgio Alex
for further details.

***IMPORTANT*** FILL OUT THIS WINNERS VERIFICATION FORM BELOW:

FULL NAME:
FULL ADDRESS:
NATIONALITY:
AGE:
OCCUPATION:
MOBILE/TELEPHONE NUMBER:
SEX:
TOTAL AMOUNT WON:

                                                           mail:     supnaltto <at> admin.in.th   

Sincerely,
Mrs. Janet James
PROMOTION CO-ORDINATOR
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] parisc: futex: Use same lock set as lws calls

In debugging the failure of the glibc tst-cond18 test on parisc, I realized
that futexes need to use the same locks the lws calls.  This fixes all the
pthread 'cond' tests.  Sadly, there are still problems with thread cancellation.

Signed-of-by: John David Anglin <dave.anglin <at> bell.net>

diff --git a/arch/parisc/include/asm/futex.h b/arch/parisc/include/asm/futex.h
index 2388bdb..a8d0586 100644
--- a/arch/parisc/include/asm/futex.h
+++ b/arch/parisc/include/asm/futex.h
 <at>  <at>  -8,6 +8,29  <at>  <at> 
 #include <asm/atomic.h>
 #include <asm/errno.h>

+/* The following has to match the LWS code in syscall.S.  We have
+   sixteen four-word locks. */
+
+static inline void
+_futex_spin_lock_irqsave (u32 __user *uaddr, unsigned long int *flags)
+{
+  extern u32 lws_lock_start[];
+  long index = ((long)uaddr & 0xf0) >> 2;
+  arch_spinlock_t *s = (arch_spinlock_t *)&lws_lock_start[index];
+  local_irq_save(*flags);
+  arch_spin_lock(s);
+}
+
+static inline void
+_futex_spin_unlock_irqrestore (u32 __user *uaddr, unsigned long int *flags)
+{

Re: [PATCH] parisc: futex: Use same lock set as lws calls

> In debugging the failure of the glibc tst-cond18 test on parisc, I
> realized
> that futexes need to use the same locks the lws calls.  This fixes all the
> pthread 'cond' tests.  Sadly, there are still problems with thread
> cancellation.
>
> Signed-of-by: John David Anglin <dave.anglin <at> bell.net>
>
> diff --git a/arch/parisc/include/asm/futex.h
> b/arch/parisc/include/asm/futex.h
> index 2388bdb..a8d0586 100644
> --- a/arch/parisc/include/asm/futex.h
> +++ b/arch/parisc/include/asm/futex.h
>  <at>  <at>  -8,6 +8,29  <at>  <at> 
>  #include <asm/atomic.h>
>  #include <asm/errno.h>
>
> +/* The following has to match the LWS code in syscall.S.  We have
> +   sixteen four-word locks. */
> +
> +static inline void
> +_futex_spin_lock_irqsave (u32 __user *uaddr, unsigned long int *flags)
> +{
> +  extern u32 lws_lock_start[];
> +  long index = ((long)uaddr & 0xf0) >> 2;
> +  arch_spinlock_t *s = (arch_spinlock_t *)&lws_lock_start[index];
> +  local_irq_save(*flags);
> +  arch_spin_lock(s);
> +}
> +

Re: [PATCH] parisc: futex: Use same lock set as lws calls

On 10-Oct-11, at 10:30 AM, Rolf Eike Beer wrote:

> This needs tabs.

Sorry, linux style isn't what I normally use.  Change has been updated  
with tabs.

Signed-off-by:  John David Anglin  <dave.anglin <at> bell.net>

Dave
--
John David Anglin	dave.anglin <at> bell.net

Re: [PATCH] parisc: futex: Use same lock set as lws calls

On Mon, 2011-10-10 at 16:27 -0400, John David Anglin wrote:
> On 10-Oct-11, at 10:30 AM, Rolf Eike Beer wrote:
> 
> > This needs tabs.
> 
> Sorry, linux style isn't what I normally use.  Change has been updated  
> with tabs.

Don't worry.  I tend to fix all of this stuff up on import, which I did
this morning when I started it in my testing environment.

James

--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: HPMC running CMake Nightly tests

On Tue, Sep 27, 2011 at 09:32:37AM +0200, Rolf Eike Beer wrote:
> I'm running the CMake tests every night. This is the second time in a row
> that my C3600 did not survive this. Since I was warned I connected a
> serial console.
...

> But then the machine got killed:
> 
> Backtrace:
>  [<1030b9ec>] tulip_get_stats+0x34/0x5c
>  [<1038ac20>] dev_get_stats+0x98/0xe8
>  [<102946b4>] led_work_func+0x11c/0x310
>  [<10145204>] process_one_work+0x120/0x3ac
>  [<10147110>] worker_thread+0x174/0x338
>  [<1014b0b4>] kthread+0x9c/0xa4
>  [<10102c5c>] ret_from_kernel_thread+0x1c/0x24
> 
> 
> High Priority Machine Check (HPMC): Code=1 regs=10551080 (Addr=00000000)
> 
>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
> PSW: 00000000000001001111111100001110 Not tainted
> r00-03  0004ff0e 105bf000 1030b9ec 2fc72000
> r04-07  0000000f 00000000 00000000 00000000
> r08-11  2fc72000 105bf600 2fea4208 7f000000
> r12-15  2fea4210 105ba000 10544000 2fc2f408
> r16-19  1041d1dc f000017c f0000174 2fea4210
> r20-23  0099f055 0099f050 1030b9b8 00000000
> r24-27  2ff57008 2fea4210 0004a040 10544000
> r28-31  0004a040 f68e066d 2fea4400 1038ac20

Re: Boot failure with 3.0.3: swapper (pid 0): Protection id trap (code 7)

>> On Tue, Sep 06, 2011 at 09:15:07AM -0500, James Bottomley wrote:
>>> It's possible that one of the flushing patches is to blame; I just
>>> can't
>>> see how.  Most likely is
>>>
>>> commit d7dd2ff11b7fcd425aca5a875983c862d19a67ae
>>> Author: James Bottomley <James.Bottomley <at> HansenPartnership.com>
>>> Date:   Thu Apr 14 18:25:21 2011 -0500
>>>
>>>     [PARISC] only make executable areas executable
>>>
>>
>> This looks promising, the second commit doesn't touch the flush_*_local,
>> so I think it's probably not a candidate.
>>
>> Rolf, can you revert d7dd2ff11b7fcd425aca5a875983c862d19a67ae and see
>> what happens?
>
> What happens is that the system boots and from a first glance seems to
> work fine.

James, are you going to revert that commit? Or am I the only one that is
seeing this?

Greetings,

Eike
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org

Re: Boot failure with 3.0.3: swapper (pid 0): Protection id trap (code 7)

On Wed, 2011-10-12 at 09:26 +0200, Rolf Eike Beer wrote:
> >> On Tue, Sep 06, 2011 at 09:15:07AM -0500, James Bottomley wrote:
> >>> It's possible that one of the flushing patches is to blame; I just
> >>> can't
> >>> see how.  Most likely is
> >>>
> >>> commit d7dd2ff11b7fcd425aca5a875983c862d19a67ae
> >>> Author: James Bottomley <James.Bottomley <at> HansenPartnership.com>
> >>> Date:   Thu Apr 14 18:25:21 2011 -0500
> >>>
> >>>     [PARISC] only make executable areas executable
> >>>
> >>
> >> This looks promising, the second commit doesn't touch the flush_*_local,
> >> so I think it's probably not a candidate.
> >>
> >> Rolf, can you revert d7dd2ff11b7fcd425aca5a875983c862d19a67ae and see
> >> what happens?
> >
> > What happens is that the system boots and from a first glance seems to
> > work fine.
> 
> James, are you going to revert that commit? Or am I the only one that is
> seeing this?

You're the only one whose seeing this.  It works 32 bit on my C360, so I
really need to know why and I don't seem to have a means to debug if
it's C3600 only.  If I revert that commit, we start segfaulting again.

James

Re: HPMC running CMake Nightly tests

> On Tue, Sep 27, 2011 at 09:32:37AM +0200, Rolf Eike Beer wrote:
>> I'm running the CMake tests every night. This is the second time in a
>> row
>> that my C3600 did not survive this. Since I was warned I connected a
>> serial console.
> ...
>
>> But then the machine got killed:
>>
>> Backtrace:
>>  [<1030b9ec>] tulip_get_stats+0x34/0x5c
>>  [<1038ac20>] dev_get_stats+0x98/0xe8
>>  [<102946b4>] led_work_func+0x11c/0x310
>>  [<10145204>] process_one_work+0x120/0x3ac
>>  [<10147110>] worker_thread+0x174/0x338
>>  [<1014b0b4>] kthread+0x9c/0xa4
>>  [<10102c5c>] ret_from_kernel_thread+0x1c/0x24
>>
>>
>> High Priority Machine Check (HPMC): Code=1 regs=10551080 (Addr=00000000)
>>
>>      YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
>> PSW: 00000000000001001111111100001110 Not tainted
>> r00-03  0004ff0e 105bf000 1030b9ec 2fc72000
>> r04-07  0000000f 00000000 00000000 00000000
>> r08-11  2fc72000 105bf600 2fea4208 7f000000
>> r12-15  2fea4210 105ba000 10544000 2fc2f408
>> r16-19  1041d1dc f000017c f0000174 2fea4210
>> r20-23  0099f055 0099f050 1030b9b8 00000000
>> r24-27  2ff57008 2fea4210 0004a040 10544000

Re: [PATCH] parisc: futex: Use same lock set as lws calls

Hi John,

On Sun, Oct 09, 2011 at 04:40:10PM -0400, John David Anglin wrote:
> In debugging the failure of the glibc tst-cond18 test on parisc, I realized
> that futexes need to use the same locks the lws calls.  This fixes all the
> pthread 'cond' tests.  Sadly, there are still problems with thread cancellation.

I applied your patch to 3.1-rc9 and tried to build Debian eglibc 2.13-21. It
passed tst-cond18 but is hanging on tst-fork1. Is it where you see the thread
cancellation issue?

Thank you for having looked at it.

Regards,
Domenico
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html