2.6.17-rc5 does not build for sparc

2.6.17-rc5 does not build for sparc

[Krzysztof Helt]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

Hello,

I tried to build the 2.6.17-rc5 for sparc with SMP enabled. The
kernel was not build due to a missing macro. Here is a patch
which fixes this (I copied the macro from a sparc64 header).

Best wishes,
Krzysztof


----------------------------------------------------
John Malkovich w filmie KLIMT.
Kontrowersyjny. Dekadencki. Rozpasany. Genialny.
W kinach od 26 maja.
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fklimt.html&sid=771

[-- Attachment #2: missing_raw_lock.patch --]
[-- Type: application/octet-stream, Size: 589 bytes --]

Only in linux-2.6.17smp/include/asm-sparc: asm-offsets.h
diff -ur linux-2.6.16/include/asm-sparc/spinlock.h linux-2.6.17smp/include/asm-sparc/spinlock.h
--- linux-2.6.16/include/asm-sparc/spinlock.h	2006-05-27 19:35:16.000000000 +0200
+++ linux-2.6.17smp/include/asm-sparc/spinlock.h	2006-05-27 21:33:28.000000000 +0200
@@ -154,6 +154,8 @@
 #define __raw_spin_lock_flags(lock, flags) __raw_spin_lock(lock)
 #define __raw_read_trylock(lock) generic__raw_read_trylock(lock)
 
+#define __raw_write_can_lock(rw)	(!(rw)->lock)
+
 #endif /* !(__ASSEMBLY__) */
 
 #endif /* __SPARC_SPINLOCK_H */

Re: 2.6.17-rc5 does not build for sparc

[Bob Breuer]

[-- Attachment #1: Type: text/plain, Size: 928 bytes --]

Krzysztof Helt wrote:
> Hello,
> 
> I tried to build the 2.6.17-rc5 for sparc with SMP enabled. The
> kernel was not build due to a missing macro. Here is a patch
> which fixes this (I copied the macro from a sparc64 header).
> 

That's not all that is broken.  I think I have what could be 4 separate
patches for smp here: (combined in the attached patch)
  1. add topology_init - fixes a boot time crash
  2. setup cpu_possible_map - actually boot the additional cpu's
  3. fix smp related section mismatch warnings
  4. add the missing *_can_lock macros

If you are running a local framebuffer, you may encounter a problem with
vmalloc.  Adding "migration_cost=10000" to the kernel command line
should cover up the problem.

I haven't had the time to give it a thorough testing and see if it
self-recompiles recently, but I was previously able to successfully
rebuild the kernel with "make -j6" on a dual SuperSPARC II.

Bob

[-- Attachment #2: sparc32-smp-2.6.17-rc4.patch --]
[-- Type: application/patch, Size: 6594 bytes --]

Re: 2.6.17-rc5 does not build for sparc

[BERTRAND Joël]

Bob Breuer a écrit :
> Krzysztof Helt wrote:
> 
>>Hello,
>>
>>I tried to build the 2.6.17-rc5 for sparc with SMP enabled. The
>>kernel was not build due to a missing macro. Here is a patch
>>which fixes this (I copied the macro from a sparc64 header).
>>
> 
> 
> That's not all that is broken.  I think I have what could be 4 separate
> patches for smp here: (combined in the attached patch)
>   1. add topology_init - fixes a boot time crash
>   2. setup cpu_possible_map - actually boot the additional cpu's
>   3. fix smp related section mismatch warnings
>   4. add the missing *_can_lock macros
> 
> If you are running a local framebuffer, you may encounter a problem with
> vmalloc.  Adding "migration_cost\x10000" to the kernel command line
> should cover up the problem.
> 
> I haven't had the time to give it a thorough testing and see if it
> self-recompiles recently, but I was previously able to successfully
> rebuild the kernel with "make -j6" on a dual SuperSPARC II.

	I have tried your patch too and I only can randomly use a SS20 with two 
SSI/75 (448 MB). I have tested the last kernel proposed on the 
debian-sparc mailing list without any trouble but with only one SSII 
(SMP is broken but I haven't seen any DMA error).

	Question : does somebody use a SS20 with four ROSS ? I have seens a 
very strange trouble. I have a lot of RT626, SS20 and memory chips. With 
all configurations I have tested with more than two RT626, Solaris 9 
returns "watchdog reset". All motherboards have been tested and work 
fine. Same observations for RT626 and memory. Thus, I don't know if the 
trouble I have seen with Linux 2.6 and 4*RT626 come from hardware 
incompatibility or software mistake. Any idea ? Currently, I retest a 
SS20 with Solaris 9 and 2*RT626 and I have built without any trouble 
gcc-4.1.0 and gcc-4.1.1.

	Regards,

	JKB

Re: 2.6.17-rc5 does not build for sparc

[Christian Joensson]

On 5/28/06, BERTRAND Joël <mt1@systella.fr> wrote:
> Bob Breuer a écrit :
> > Krzysztof Helt wrote:
> >
> >>Hello,
> >>
> >>I tried to build the 2.6.17-rc5 for sparc with SMP enabled. The
> >>kernel was not build due to a missing macro. Here is a patch
> >>which fixes this (I copied the macro from a sparc64 header).
> >>
> >
> >
> > That's not all that is broken.  I think I have what could be 4 separate
> > patches for smp here: (combined in the attached patch)
> >   1. add topology_init - fixes a boot time crash
> >   2. setup cpu_possible_map - actually boot the additional cpu's
> >   3. fix smp related section mismatch warnings
> >   4. add the missing *_can_lock macros
> >
> > If you are running a local framebuffer, you may encounter a problem with
> > vmalloc.  Adding "migration_cost\x10000" to the kernel command line
> > should cover up the problem.
> >
> > I haven't had the time to give it a thorough testing and see if it
> > self-recompiles recently, but I was previously able to successfully
> > rebuild the kernel with "make -j6" on a dual SuperSPARC II.
>
>         I have tried your patch too and I only can randomly use a SS20 with two
> SSI/75 (448 MB). I have tested the last kernel proposed on the
> debian-sparc mailing list without any trouble but with only one SSII
> (SMP is broken but I haven't seen any DMA error).
>
>         Question : does somebody use a SS20 with four ROSS ? I have seens a
> very strange trouble. I have a lot of RT626, SS20 and memory chips. With
> all configurations I have tested with more than two RT626, Solaris 9
> returns "watchdog reset". All motherboards have been tested and work
> fine. Same observations for RT626 and memory. Thus, I don't know if the
> trouble I have seen with Linux 2.6 and 4*RT626 come from hardware
> incompatibility or software mistake. Any idea ? Currently, I retest a
> SS20 with Solaris 9 and 2*RT626 and I have built without any trouble
> gcc-4.1.0 and gcc-4.1.1.

sorry, I had one, quad 150 MHz, but I threw it away in january, 2.2
worked but not 2.4, and sparc32 smp is as far as I understand... well,
dead in 2.6....


-- 
Cheers,

/ChJ

Re: 2.6.17-rc5 does not build for sparc

[Krzysztof Helt]

Dnia 28-05-2006 o godz. 0:43 Bob Breuer napisa³:
 
> That's not all that is broken.  I think I have what could be 4
separate
> patches for smp here: (combined in the attached patch)
>   1. add topology_init - fixes a boot time crash
>   2. setup cpu_possible_map - actually boot the additional cpu's
>   3. fix smp related section mismatch warnings
>   4. add the missing *_can_lock macros
> 
> If you are running a local framebuffer, you may encounter a
problem with
> vmalloc.  Adding "migration_cost\x10000" to the kernel command line
> should cover up the problem.
> 

Thank you for the patch. It's a pity you haven't post it earlier
as I lost few hours fixing missing topology_init.

Anyway, it is a huge improvement other the current state of
official kernel. Is this patch on its way to the kernel?

> I haven't had the time to give it a thorough testing and see if it
> self-recompiles recently, but I was previously able to successfully
> rebuild the kernel with "make -j6" on a dual SuperSPARC II.
> 

I was not so lucky. I was able to boot and two cpus were detected
 (Supersparc II) but the machine opened PROM console after
mounting tmpfs filesystem (for the /tmp directory). The harddisk
filesystems were mounted correctly. I will try to look into this
problem.

Krzysztof

Re: 2.6.17-rc5 does not build for sparc

[David Miller]

From: "Krzysztof Helt" <krzysztof.h1@wp.pl>
Date: Sat, 27 May 2006 23:09:17 +0200

> I tried to build the 2.6.17-rc5 for sparc with SMP enabled. The
> kernel was not build due to a missing macro. Here is a patch
> which fixes this (I copied the macro from a sparc64 header).

I was going to apply this just to fix the build, but it's
not correct.

Because we embed a spinlock in the rwlock_t, we have to spin
waiting for the lock bits to be clear before we can trust the
sample of the rest of the lock.  We used to have to do this
when we embedded a spinlock into the atomic_t's on sparc32.

Re: 2.6.17-rc5 does not build for sparc

[Bob Breuer]

David Miller wrote:
> From: "Krzysztof Helt" <krzysztof.h1@wp.pl>
> Date: Sat, 27 May 2006 23:09:17 +0200
> 
>> I tried to build the 2.6.17-rc5 for sparc with SMP enabled. The
>> kernel was not build due to a missing macro. Here is a patch
>> which fixes this (I copied the macro from a sparc64 header).
> 
> I was going to apply this just to fix the build, but it's
> not correct.
> 
> Because we embed a spinlock in the rwlock_t, we have to spin
> waiting for the lock bits to be clear before we can trust the
> sample of the rest of the lock.  We used to have to do this
> when we embedded a spinlock into the atomic_t's on sparc32.

Correct me if I am wrong, but...

From asm-sparc/spinlock.h:

 *      ------------------------------------
 *      | 24-bit counter           | wlock |  raw_rwlock_t
 *      ------------------------------------
 *       31                       8 7     0
 *
 * wlock signifies the one writer is in or somebody is updating
 * counter. For a writer, if he successfully acquires the wlock,
 * but counter is non-zero, he has to release the lock and wait,
 * till both counter and wlock are zero.


rw->lock in this case is the full 32-bit raw_rwlock_t, so a value of
0x000000ff is locked by a writer, 0x00000100 would be locked by a
reader, and 0x000001ff would be locked by a reader and updating the counter.

For __raw_write_can_lock(), we should be able to return true when the
whole 32-bits is zero (i.e. no readers, no counter being updated, and no
writers).  rw->lock is the whole 32-bits, so a check of !(rw)->lock
should be the right thing.

While we are at it, another one we are missing is __raw_read_can_lock(),
and I think that a check of !((rw)->lock & 0xff) will work (i.e. no
writers and no updating of the counter), or might it be better if the
counter was negated and we checked  rw->lock <= 0 ?

Bob

Re: 2.6.17-rc5 does not build for sparc

[David Miller]

From: Bob Breuer <breuerr@mc.net>
Date: Mon, 05 Jun 2006 23:59:29 -0500

> rw->lock in this case is the full 32-bit raw_rwlock_t, so a value of
> 0x000000ff is locked by a writer, 0x00000100 would be locked by a
> reader, and 0x000001ff would be locked by a reader and updating the counter.

For a moment I thought you were right, but the spinlock acts
to atomicize the reader counter updates too.

That lock could be set transiently, while decrementing the
reader counter down to zero.

So it really does matter, and in fact you have to be even more
careful that I originally indicated.  In fact I can't even see
how you can implement this %100 correctly.

We simply can't tell if the spinlock is held because the writer
is trying to get in, or because a reader is holding is just to
increment or decrement the counter.

If the reader count is zero, for example, the spinlock could be held
by a writer and we don't want to spin waiting for it to clear in that
case.  If, however, the reader count is zero but the spinlock is
held so that a reader can increment the count, we would want to
spin waiting for the spinlock to release in that case.

There is a way to fix this.  Rewrite the rwlock stuff to use the
atomic_t hashed spinlocks to update rwlock_t and just modify it
as a 32-bit atomically updatable value just like platforms which
have compare-and-swap primitives do.

Then we could implement the "can lock" primitives just like the
other platforms do.

Re: 2.6.17-rc5 does not build for sparc

[Bob Breuer]

David Miller wrote:
> From: Bob Breuer <breuerr@mc.net>
> Date: Mon, 05 Jun 2006 23:59:29 -0500
> 
>> rw->lock in this case is the full 32-bit raw_rwlock_t, so a value of
>> 0x000000ff is locked by a writer, 0x00000100 would be locked by a
>> reader, and 0x000001ff would be locked by a reader and updating the counter.
> 
> For a moment I thought you were right, but the spinlock acts
> to atomicize the reader counter updates too.

Is it ok if the can_lock macros are conservative and maybe return a
false failure?

> That lock could be set transiently, while decrementing the
> reader counter down to zero.
> 
> So it really does matter, and in fact you have to be even more
> careful that I originally indicated.  In fact I can't even see
> how you can implement this %100 correctly.

Even if can_lock() is 100% correct, there is no guarantee that the lock
will still be available right after, only a trylock could give that kind
of guarantee.

> We simply can't tell if the spinlock is held because the writer
> is trying to get in, or because a reader is holding is just to
> increment or decrement the counter.

If we can't tell, then be conservative and return 0.

> If the reader count is zero, for example, the spinlock could be held
> by a writer and we don't want to spin waiting for it to clear in that
> case.  If, however, the reader count is zero but the spinlock is
> held so that a reader can increment the count, we would want to
> spin waiting for the spinlock to release in that case.

The can_lock macros never need to spin.

Ok, how about a truth table to cover all combinations:

reader count | wlock | lock value | write_can_lock | read_can_lock
-------------+-------+------------+----------------+--------------
1)     0     |   0   | 000000 00  |       1        |      1
2)     0     | not 0 | 000000 xx  |       0        |      0
3)   not 0   |   0   | xxxxxx 00  |       0        |      1
4)   not 0   | not 0 | xxxxxx xx  |       0        |      0

reader count and wlock are part the _same_ 32-bit value, therefore when
we read the value we get a simultaneous snapshot of both and it must be
in one of these 4 states.

State 2 is a questionable state and could be caused by either a reader
or a writer, therefore neither one can be guaranteed to succeed.

State 4 would be a bigger concern because read_can_lock() could be
expected to return true, but then again the caller must be expecting
potential failure, or they wouldn't be checking with can_lock.

Re: 2.6.17-rc5 does not build for sparc

[Krzysztof Helt]

My two cents to this discussion.

I consider both of these macros (write_can_lock and
read_can_lock) brain-damaged as they do not guarantee anything. 
That's why I haven't copied the read_can_lock macro - it is not
used in the sparc kernel and let it be this way.

The write_can_lock is used in one place only - in ptrace.c file
when it is used to add a little efficiency into a waiting for two
spinlocks to be free. I suppose this call can be removed but I
afraid changing it. A whole idea there is simple: obtain one
lock, try to obtain another one and if it is not successful use
the write_can_lock macro to wait before repeating former steps. I
think that without this macro the waiting may become less
efficient - more trials of obtaining lock will be made. See the
code below:

repeat:
    /*
     * Nasty, nasty.
     *
     * We want to hold both the task-lock and the
     * tasklist_lock for writing at the same time.
     * But that's against the rules (tasklist_lock
     * is taken for reading by interrupts on other
     * cpu's that may have task_lock).
     */
    task_lock(task);
    local_irq_disable();
    if (!write_trylock(&tasklist_lock)) {
        local_irq_enable();
        task_unlock(task);
        do {
            cpu_relax();
        } while (!write_can_lock(&tasklist_lock));
        goto repeat;
    }

There is no need for this macro to be 100% accurate. It is enough
to be conservative as Bob Breuer suggested (it should not spin
waiting either). The other way is to remove the call to
write_can_lock from the code above.

I beg you (sparc32 maintainers) to start pushing smp patches (or
even parts of them) into the kernel tree. I have another patch
which clears sun4m_smp.c a little (replaced loops with
for_each_online_cpu, removed one unused global variable) but this
will stop Bob Breuer's patch from applying so I wait sitting on it.

I am able to boot a dual SM81 in SS20 with all the smp patches
from this list, but the kernel hangs on first module load. It is
something I will investigate.

Regards,
Krzysztof


----------------------------------------------------
Nowe serie superksi±¿ek o Czarodziejkach WITCH!
Poznaj ¶wiat bohaterek WITCH! 
Will, Irma, Taranee, Cornelia i Hay-Lin zapraszaj± do ksiêgarni.
http://klik.wp.pl/?adr=http%3A%2F%2Fadv.reklama.wp.pl%2Fas%2Fwitch.html&sidx1