On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
So you need to build a different kernel for some types of MIPS systems?
Or do you do boot-time rewriting, like a number of other arches do?
I don't know. I would like to have responses. Ralf
On 01/27/2016 03:26 AM, Maciej W. Rozycki wrote:
On Fri, 15 Jan 2016, Leonid Yegoshin wrote:
So you need to build a different kernel for some types of MIPS systems?
Or do you do boot-time rewriting, like a number of other arches do?
I don't know. I would like to have responses. Ralf
work, which means that the SYNC in P1 must
also capture the store in P0 as being "before" the barrier. Leonid
reckons it works, but his explanation [2] focussed on the address
dependency in P2 as to why this works. If that is the case (i.e.
address dependency provi
On 01/14/2016 04:47 PM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 03:33:40PM -0800, Leonid Yegoshin wrote:
Don't be fooled here by words "ordered" and "completed" - it is HW
design items and actually written poorly.
Just assume that SYNC_MB is absolutely the sam
t way but nobody
knows or test it. But as a minimum - SYNC must be implemented in
spinlocks/atomics/bitops, in recent P5600 it is proven that read can
pass write in atomics.
MIPS R6 is a different story, I verified lightweight SY
bitops for
Imagination MIPS CPUs too - it is just absent now for any Imagination
MIPS CPUs!
Michael later pointed me that it can be returned back with his series of
patches but discussion was already here.
- Leonid.
___
Linuxppc-dev mailing list
Li
On 01/14/2016 01:34 PM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 12:46:43PM -0800, Leonid Yegoshin wrote:
On 01/14/2016 12:15 PM, Peter Zijlstra wrote:
On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
An the only point - please use an appropriate SYNC_* barriers instead
o any barrier. lockless_dereference() has a barrier.
I don't see a common points between this and that in your answer, sorry.
- Leonid.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
rforms "local ordering for address and
data dependencies" too.
- Leonid.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Transitivity is
Peter Zijlstra recently wrote: "In particular we're very much all
'confused' about the various notions of transitivity". I am confused
too, so - please use some more simple way to explain your words. Sorry,
but we need a common ground first.
- Leonid.
On 01/14/2016 12:15 PM, Peter Zijlstra wrote:
On Thu, Jan 14, 2016 at 11:42:02AM -0800, Leonid Yegoshin wrote:
An the only point - please use an appropriate SYNC_* barriers instead of
heavy bold hammer. That stuff was design explicitly to support the
requirements of Documentation/memory
What else do you want from me - RTL or microArch design for that?
- Leonid.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 01/14/2016 08:16 AM, Paul E. McKenney wrote:
On Thu, Jan 14, 2016 at 12:04:45PM +, Will Deacon wrote:
On Wed, Jan 13, 2016 at 12:58:22PM -0800, Leonid Yegoshin wrote:
On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
I ask
On 01/14/2016 04:14 AM, Will Deacon wrote:
On Wed, Jan 13, 2016 at 02:26:16PM -0800, Leonid Yegoshin wrote:
Moreover, there are voices against guarantee that it will be in future
and that voices point me to Documentation/memory-barriers.txt section "DATA
DEPENDENCY BARRIERS"
n my mind. I just want to be sure
that this patchset still provides a use of a specific lightweight SYNCs
on MIPS vs bold and heavy generalized "SYNC 0" in any case.
- Leonid.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On 01/13/2016 12:48 PM, Peter Zijlstra wrote:
On Wed, Jan 13, 2016 at 11:02:35AM -0800, Leonid Yegoshin wrote:
I ask HW team about it but I have a question - has it any relationship with
replacing MIPS SYNC with lightweight SYNCs (SYNC_WMB etc)?
Of course. If you cannot explain the semantics
On 01/13/2016 02:45 AM, Will Deacon wrote:
On Tue, Jan 12, 2016 at 12:45:14PM -0800, Leonid Yegoshin wrote:
I don't think the address dependency is enough on its own. By that
reasoning, the following variant (WRC+addr+addr) would work too:
P0:
Wx = 1
P1:
Rx == 1
Wy = 1
P2:
Ry ==
.
- It is not applied to instruction fetch. However, I-Cache flushes
and SYNCI are consistent with that. There is also hazard barrier
instructions to clear CPU pipeline to some extent - to help with this
limitation.
I don't think that these caveats prevent a correct Acquire/Re
te address of X. If some load of X in P2 happens before
address dependency calculation it's result is discarded.
Yes, you can't find that in MIPS SYNC instruction description, it is
more likely in CM (Coherence Manager) area. I just pointed our arch team
member responsible for docum
statement doesn't fit MIPS barriers variations. Moreover, there is
a reason to extend that even more specific, at least for
smp_store_release and smp_load_acquire, look into
http://patchwork.linux-mips.org/patch/10506/
- Leonid.
___
Linuxpp
Hi
This is my first mail in this group , so I hope this is the right place
for it.
I am testing myri10ge pci-e (10G ethernet card) on p4080(freescale
powerpc) evaluation board.
using kernel 2.6.34.6
when I am trying to insert myri10ge kernel module, I getting :
"myri10ge: Version 1.5.2-1.459
Please unsubscribe me from this list.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
minal must be
cleaned then.
You also can try "dirty" hack to ensure framebuffer functionality. Type:
sh > /dev/tty1 2>&1 < /dev/tty1
You must get prompt on monitor (your serial will hang) and if you have
working (USB?) keyboard, you will be able to use monitor.
Th
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:netdev-
> [EMAIL PROTECTED] On Behalf Of Andrew Gallatin
> Sent: Monday, July 30, 2007 10:43 AM
> To: Linas Vepstas
> Cc: Jan-Bernd Themann; netdev; Thomas Klein; Jeff Garzik; Jan-Bernd
> Themann; linux-kernel; linux-ppc; Christoph Ra
24 matches
Mail list logo
