* Re: How to boot powerPC linux-2.6.10 from diifferent address other than 0x0000
From: Reeve Yang @ 2006-08-28 23:37 UTC (permalink / raw)
To: Reddy Suneel-ASR125; +Cc: linuxppc-embedded
In-Reply-To: <405ECA8A30557F439A723E52D50838F9D372AB@ZMY16EXM66.ds.mot.com>
[-- Attachment #1: Type: text/plain, Size: 1531 bytes --]
You need to do two things:
- mem remap your boot sector memory block to virtual address 0xc0008000
- using uboot commond "go xxx" to boot it from 0xc0008000, or define env
variable "bootcmd", and run "boot".
On 8/25/06, Reddy Suneel-ASR125 <suneel.reddy@motorola.com> wrote:
>
> Hi,
> We are working on MPC 8540, Linux kernel version is 2.6.10 from
> Montavista. The bootloader used in Uboot and currently it loads the uImage
> at physical memory address 0x0 and transfers control to it. We want to load
> the kernel at a different address say 0x8000 and for this we made the
> following changes.
>
> 1) Altered the Makefile to linked the kernel at virtual address 0xc0008000
> ( the default was 0xc000:0000)
> 2) Modified Uboot to load kernel at 0x8000 instead of 0x0
>
> The kernel space still starts from 0xc000:0000
>
> When we transferred control to the kernel (loaded at 0x8000) we found that
> the execution proceeds only till the mapping and invalidation on TLBs. We do
> not know where the control goes after this as the further instructions does
> not seems to get executed. Currently we do not have the provision to connect
> a debugger and hence we are unable to make out what is happening.
>
> Can some one give us any clue as to what we might have done wrong? This is
> our first experience on PowerPC.
>
>
> Thanks®ards
> Suneel
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
[-- Attachment #2: Type: text/html, Size: 3256 bytes --]
^ permalink raw reply
* Re: copy_4K_page() doesn't use dcbtst?
From: Paul Mackerras @ 2006-08-29 0:16 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev, xen-ppc-devel
In-Reply-To: <1156786523.28490.52.camel@basalt.austin.ibm.com>
Hollis Blanchard writes:
> Hi Paul, some Xen people were just noticing that copy_4K_page
> (arch/powerpc/lib/copypage_64.S) doesn't use the dcbtst instruction. Why
> doesn't it help there?
Why would we want to read the cache lines for the destination from
memory when we're only going to overwrite them completely anyway?
A stronger argument would be for using dcbz, but IIRC it actually made
things slower (on POWER4 at least). I suspect the hardware is
gathering the stores for the whole of each cache line automatically,
so using dcbz doesn't provide any benefit.
I did a lot of measurements of memory copy speed on POWER4 (using
different copy loops, copy sizes, alignments, cache hot/cold cases)
and the copy_4K_page loop is the fastest I could come up with for
POWER4. If anyone can come up with a routine that is measurably
faster on current machines, I'm happy to look at it, of course.
Paul.
^ permalink raw reply
* RE: atomic operations in user space
From: Xupei Liang @ 2006-08-29 0:43 UTC (permalink / raw)
To: linuxppc-embedded
I think it is less expensive using atomic operation
sometimes in the user space, e.g. when updating a
counter. If this counter is to be updated by a lot of
processes, using semaphore can potentially cause a lot
of task switching.
Regards,
Terry Liang
> -----Original Message-----
> From: Brent Cook [mailto:bcook at bpointsys.com]
> Sent: Thursday, August 24, 2006 10:18 PM
> To: linuxppc-embedded at ozlabs.org
> Cc: Li Yang-r58472; Terry Liang
> Subject: Re: atomic operations in user space
>
> On Thursday 24 August 2006 05:39, Li Yang-r58472
wrote:
>
> > Why do you need atomic operations in user land?
IPC will be
sufficient
>
> > to deal with race conditions between processes.
>
> >
>
> > Best Regards,
>
> > Leo
>
> What about multiple threads within a process
updating a counter?
Is there anything preventing semaphore to be used in
threads?
>
> Of course, if you look at these functions in the
kernel header,
they're just 2 or
> 3 inline assembly calls - you could easily rewrite
them. Google for
'PowerPC atomic
> increment' and grab one of the unencumbered
implementations if you
need to use it
> in a non-GPL program.
>
> On the other hand, I see no license at the top of my
/usr/include/asm-i386/atomic.h
> file at all, same for PowerPC - are Linux header
files actually GPL or
are they
> more like the glibc headers, with exceptions made
for userspace
programs?
>
> The atomic operations on x86 were accidentally
exported early on, so
they have to
> hang around apparently for compatibility (there are
some mailing list
threads out
> there to this effect.) Currently, you just have to
assume in Linux
that if you
> include something from /usr/include/linux or asm
that it will not
necessarily be
> cross-version or cross-architecture compatible. Not
every arch in
Linux even has
> atomic operations of this nature, which I guess is
the main reason why
they are
> not exported in general.
>
> - Brent
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: PPC405 system slow boot
From: Peter Ryser @ 2006-08-29 0:45 UTC (permalink / raw)
To: Clint Thomas; +Cc: linuxppc-embedded
In-Reply-To: <3C02138692C13C4BB675FE7EA240952918E1E2@bluefin.Soneticom.local>
[-- Attachment #1: Type: text/plain, Size: 1851 bytes --]
Clint,
check the interrupt sub-system of your design. What you describe
typically happens when the PPC does not get any interrupts from the
UART. It's most likely a mismatch between your hardware and the
xparameters.h.
- Peter
Clint Thomas wrote:
> Hey guys,
>
> I've run through the loops to try and figure what could be wrong with
> this system. The board in question is modeled after the Xilinx ML300
> board. It uses a Xilinx System ACE chip to load a FPGA / Kernel image
> from compact flash. Originally, I was trying to use the CompactFlash
> as the root file system, but because of issues in either the design or
> software, this would only work if SysAce was in polled I/O mode. To
> circumvent this, I built my root filesystem into an initrd image and
> built a single ELF file with the Kernel and RFS, then strapped that to
> the FPGA bit file to make a single FPGA/Kernel/RFS SysAce file.
>
> Upon decompression, the Linux kernel boots quickly and loads all of
> the device drivers. However when it gets to the prompt, it starts
> slowing down. Output and input to and from the board becomes very very
> slow (it displays 2 characters roughly every 20 seconds). Originally I
> believed this to be the CPU still polling SystemAce, so I disabled the
> Linux System ACE drivers to remove that as a possibility, however
> after doing this, the problem still persists, even with the RFS in
> ram! Has anybody encountered a similar situation to this before, with
> possible insight towards a solution? Thank you for your time.
>
> Clinton Thomas
> cthomas@soneticom.com
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
[-- Attachment #2: Type: text/html, Size: 2704 bytes --]
^ permalink raw reply
* PPC 2.6.11.4 kernel panics while doing insmod (store fault with d cbst in icache_flush_range)
From: Kallol Biswas @ 2006-08-29 1:53 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev
Cc: Ronald Lee, linuxppc-dev, Radjendirane Codandaramane, Shawn Jin
I have been getting an "oops" while doing insmod.
Sys_init_module() -> Load_module() -> module_alloc(mod->core_size)
Mod->core_size is = 0x1ff4
A few lines from module_alloc() routine:
ptr = module_alloc(mod->core_size); // core_size is 0x1ff4
if (!ptr) {
err = -ENOMEM;
goto free_percpu;
}
memset(ptr, 0, mod->core_size);
mod->module_core = ptr;
Module_alloc calls vmalloc, which populates the page tables entries; no TLB entry is updated at this moment for the newly vmalloc'd memory.
Next, when memset is done, we do see two TLB entries are allocated one for each page (ptr == D21B8000, core_size being 0x1ff4 we need two pages).
0x0000-0000
0xD21B-8210
0x0063-B000
0x0000-0107
0x0000-0000
0xD21B-9210
0x0063-7000
0x0000-0107
A few lines from sys_init_module()
/* Do all the hard work */
mod = load_module(umod, len, uargs);
if (IS_ERR(mod)) {
up(&module_mutex);
return PTR_ERR(mod);
}
/* Flush the instruction cache, since we've played with text */
if (mod->module_init)
flush_icache_range((unsigned long)mod->module_init,
(unsigned long)mod->module_init
+ mod->init_size);
flush_icache_range((unsigned long)mod->module_core,
(unsigned long)mod->module_core + mod->core_size);
Next, at the routine
flush_icache_range((unsigned long)mod->module_core,
(unsigned long)mod->module_core + mod->core_size);
we see that one of the TLB entries is not present, which is probably normal.
A few lines from flush_icache_range():
mr r6,r3
1: dcbst 0,r3
addi r3,r3,L1_CACHE_LINE_SIZE
bdnz 1b
The instruction takes a store fault (DST bit, bit 8 of ESR gets set), kernel panics with oops (signal 11).
It is probably normal that the TLB entry for vmalloc'd memory may not be present.
How do we fix the problem?
We do see the problem only when we have big drivers compiled into the kernel.
Thanks,
Kallol
^ permalink raw reply
* RE: [QUESTION] Enable coherency for all pages on 83xx to fix PCI data corruption
From: Liu Dave-r63238 @ 2006-08-29 2:04 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <4495EF77-BC25-45B9-AC7B-BFCEBC619510@kernel.crashing.org>
> This was to address PCI5 if I remember correctly.
>=20
> - kumar
>=20
> On Aug 28, 2006, at 2:49 AM, Liu Dave-r63238 wrote:
>=20
> > All,
> >
> > I want to know which PCI errata is solved by this patch and if this=20
> > patch did test on real hardware.
> >
> > I know this patch turn on the 'M' bit -memory coherency.
> > But I don't believe this can solved the "PCI read multi-line"
> > errata.
> >
> > -DAve
<snip>
I also don't believe this patch can solve the PCI5 errata, The PCI5
description:
When external PCI devices try to read from the memory which is defined
as
prefetchable and where the transaction is more than one cache line,
there
may be data corruption.
-DAve
^ permalink raw reply
* RE: MPC83xx and Gianfar Drive Oops
From: Liu Dave-r63238 @ 2006-08-29 2:12 UTC (permalink / raw)
To: SIP COP 009, linuxppc-embedded
In-Reply-To: <5a4792c00608281633p4921016fn62a6f7cedba9e03@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2368 bytes --]
Do testing with the latest kernel version,
see if it still have the oops.
________________________________
From: linuxppc-embedded-bounces+daveliu=freescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+daveliu=freescale.com@ozlabs.org] On
Behalf Of SIP COP 009
Sent: Tuesday, August 29, 2006 7:34 AM
To: linuxppc-embedded@ozlabs.org
Cc: sipcop009@gmail.com
Subject: MPC83xx and Gianfar Drive Oops
Folks,
Anyone seen this before ?
We have the MPC8349 based EVM board which has 2 GigEs. IP
forwarding is enabled on the system. The kernel/gianfar is 2.6.11
based.
We were trying to stress the GigE interfaces by sending
bidirectional smartbits traffic.
We observe the following kernel oops:
e-99-0-21-1# Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C016EB80 LR: C016EB80 SP: C0241DE0 REGS: c0241d30 TRAP:
0700
Tainted: P
MSR: 00029032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11 TASK =
c022bdb0[0] 'swapper' THREAD: c0240000 Last syscall: 120
GPR00: C016EB80 C0241DE0 C022BDB0 00000030 C0263BF4 000001A1
DF700060 3B9ACA00
GPR08: C0263BF8 C023DB24 DEA5DE9C C0241CF0 00003C9B 1001A1F8
1FFF8000 00000000
GPR16: FFFFFFFF 00000001 00000000 1FFF297C 1FF9E330 00000001
007FFF00 C0230000
GPR24: 00000001 0000FFFC DFD6B800 0000003F DDC42F48 00000000
D7FA9140 DFD6BA20 Call trace: [c01495d4] [c0149748] [c0176078]
[c0018d34] [c0018e00] [c0005438] [c000460c] [c00038ac] [c00054d0]
[c0003928] [c0242674] [000035fc] Kernel panic - not syncing: Aiee,
killing interrupt handler!
<0>Rebooting in 180 seconds..
After decoding this it looks like the following:
Enter hex value: c01495d4
0xc01495d4:gfar_error(0xc01494bc)+0x118
Enter hex value: c0149748
0xc0149748:gfar_gdrvinfo(0xc0149718)+0x30
Enter hex value: c0176078
0xc0176078:dev_ioctl(0xc0175f0c)+0x16c
Enter hex value: c0018d34
0xc0018d34:__do_softirq(0xc0018cb4)+0x80
Enter hex value: c0018e00
0xc0018e00:do_softirq(0xc0018da8)+0x58
Enter hex value: c0005438
0xc0005438:do_IRQ(0xc00053b4)+0x84
Enter hex value: c000460c
0xc000460c:ret_from_except(0xc000460c)+0x0
Enter hex value: c00038ac
0xc00038ac:ppc6xx_idle(0xc00037c8)+0xe4
Enter hex value: c00054d0
0xc00054d0:cpu_idle(0xc00054a8)+0x28
Any idea on this one ? Any new fixes that went in for such
issues ?
Thanks!
ashutosh
[-- Attachment #2: Type: text/html, Size: 3352 bytes --]
^ permalink raw reply
* Re: copy_4K_page() doesn't use dcbtst?
From: Hollis Blanchard @ 2006-08-29 2:11 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, xen-ppc-devel
In-Reply-To: <17651.34629.132793.190742@cargo.ozlabs.ibm.com>
On Tue, 2006-08-29 at 10:16 +1000, Paul Mackerras wrote:
> Hollis Blanchard writes:
>
> > Hi Paul, some Xen people were just noticing that copy_4K_page
> > (arch/powerpc/lib/copypage_64.S) doesn't use the dcbtst instruction. Why
> > doesn't it help there?
>
> Why would we want to read the cache lines for the destination from
> memory when we're only going to overwrite them completely anyway?
>
> A stronger argument would be for using dcbz, but IIRC it actually made
> things slower (on POWER4 at least). I suspect the hardware is
> gathering the stores for the whole of each cache line automatically,
> so using dcbz doesn't provide any benefit.
Yes, dcbz makes more sense.
> I did a lot of measurements of memory copy speed on POWER4 (using
> different copy loops, copy sizes, alignments, cache hot/cold cases)
> and the copy_4K_page loop is the fastest I could come up with for
> POWER4. If anyone can come up with a routine that is measurably
> faster on current machines, I'm happy to look at it, of course.
I figured you had done measurements; we were just curious about the
unexpected results. Thanks!
--
Hollis Blanchard
IBM Linux Technology Center
^ permalink raw reply
* MPC85xx u-boot definition
From: enorm @ 2006-08-29 1:54 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
Hi,
Some naive questions about u-boot for MPC85xx, the definition of
some macro in ppc_asm.tmpl. Can anyone there explain them to me please?
1) In GET_GOT(x) what does " lwz r0,0b-1b(r14) ;" do? what does
"0b-1b" stands for, or the meaning of the syntax? why move the content
of the memory pointing by LR?
#define GET_GOT \
bl 1f ; \
.text 2 ; \
0: .long .LCTOC1-1f ; \
.text ; \
1: mflr r14 ; \
lwz r0,0b-1b(r14) ; \
add r14,r0,r14 ;
2) In START_GOT, any special meaning for the value 32768?
>> .LCTOC1=.+32768
3) Syntax for GOT_ENTRY(NAME) and GOT(NAME), like . - .LCTOC1 (line 57) and .text 2 (line 50)
could not find then in the GNU douments (ld, as, gcc, glibc etc).
Thanks for the help!!
[-- Attachment #2: Type: text/html, Size: 2166 bytes --]
^ permalink raw reply
* RE: [PATCH] corrected PCI interrupt sense values to level low inmpc8349emds.dts
From: Liu Dave-r63238 @ 2006-08-29 2:32 UTC (permalink / raw)
To: Phillips Kim-R1AAHA, linuxppc-dev
In-Reply-To: <20060828174910.236bf042.kim.phillips@freescale.com>
> Corrected PCI interrupt sense values to level low in=20
> mpc8349emds.dts, per Leo's recommendation.
>=20
> Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
> ---
>=20
> applies on top of "[PATCH 4/4] Add MPC8349E MDS device tree=20
> source file to arch/powerpc/boot/dts"
>=20
>=20
> arch/powerpc/boot/dts/mpc8349emds.dts | 112=20
> +++++++++++++++++----------------
> 1 files changed, 56 insertions(+), 56 deletions(-)
>=20
> diff --git a/arch/powerpc/boot/dts/mpc8349emds.dts=20
> b/arch/powerpc/boot/dts/mpc8349emds.dts
> index 7e4508b..0643db9 100644
> --- a/arch/powerpc/boot/dts/mpc8349emds.dts
> +++ b/arch/powerpc/boot/dts/mpc8349emds.dts
> @@ -178,46 +178,46 @@
> interrupt-map =3D <
> =20
> /* IDSEL 0x11 */
> - 8800 0 0 1 700 14 0
> - 8800 0 0 2 700 15 0
> - 8800 0 0 3 700 16 0
> - 8800 0 0 4 700 17 0
> + 8800 0 0 1 700 14 2
> + 8800 0 0 2 700 15 2
> + 8800 0 0 3 700 16 2
> + 8800 0 0 4 700 17 2
> =20
> /* IDSEL 0x12 */
> - 9000 0 0 1 700 16 0
> - 9000 0 0 2 700 17 0
> - 9000 0 0 3 700 14 0
> - 9000 0 0 4 700 15 0
> + 9000 0 0 1 700 16 2
> + 9000 0 0 2 700 17 2
> + 9000 0 0 3 700 14 2
> + 9000 0 0 4 700 15 2
> =20
> /* IDSEL 0x13 */
> - 9800 0 0 1 700 17 0
> - 9800 0 0 2 700 14 0
> - 9800 0 0 3 700 15 0
> - 9800 0 0 4 700 16 0
> + 9800 0 0 1 700 17 2
> + 9800 0 0 2 700 14 2
> + 9800 0 0 3 700 15 2
> + 9800 0 0 4 700 16 2
> =20
> /* IDSEL 0x15 */
> - a800 0 0 1 700 14 0
> - a800 0 0 2 700 15 0
> - a800 0 0 3 700 16 0
> - a800 0 0 4 700 17 0
> + a800 0 0 1 700 14 2
> + a800 0 0 2 700 15 2
> + a800 0 0 3 700 16 2
> + a800 0 0 4 700 17 2
> =20
> /* IDSEL 0x16 */
> - b000 0 0 1 700 17 0
> - b000 0 0 2 700 14 0
> - b000 0 0 3 700 15 0
> - b000 0 0 4 700 16 0
> + b000 0 0 1 700 17 2
> + b000 0 0 2 700 14 2
> + b000 0 0 3 700 15 2
> + b000 0 0 4 700 16 2
> =20
> /* IDSEL 0x17 */
> - b800 0 0 1 700 16 0
> - b800 0 0 2 700 17 0
> - b800 0 0 3 700 14 0
> - b800 0 0 4 700 15 0
> + b800 0 0 1 700 16 2
> + b800 0 0 2 700 17 2
> + b800 0 0 3 700 14 2
> + b800 0 0 4 700 15 2
> =20
> /* IDSEL 0x18 */
> - b000 0 0 1 700 15 0
> - b000 0 0 2 700 16 0
> - b000 0 0 3 700 17 0
> - b000 0 0 4 700 14 0>;
> + b000 0 0 1 700 15 2
> + b000 0 0 2 700 16 2
> + b000 0 0 3 700 17 2
> + b000 0 0 4 700 14 2>;
> interrupt-parent =3D <700>;
> interrupts =3D <42 8>;
> bus-range =3D <0 0>;
> @@ -238,46 +238,46 @@
> interrupt-map =3D <
> =20
> /* IDSEL 0x11 */
> - 8800 0 0 1 700 14 0
> - 8800 0 0 2 700 15 0
> - 8800 0 0 3 700 16 0
> - 8800 0 0 4 700 17 0
> + 8800 0 0 1 700 14 2
> + 8800 0 0 2 700 15 2
> + 8800 0 0 3 700 16 2
> + 8800 0 0 4 700 17 2
> =20
> /* IDSEL 0x12 */
> - 9000 0 0 1 700 16 0
> - 9000 0 0 2 700 17 0
> - 9000 0 0 3 700 14 0
> - 9000 0 0 4 700 15 0
> + 9000 0 0 1 700 16 2
> + 9000 0 0 2 700 17 2
> + 9000 0 0 3 700 14 2
> + 9000 0 0 4 700 15 2
> =20
> /* IDSEL 0x13 */
> - 9800 0 0 1 700 17 0
> - 9800 0 0 2 700 14 0
> - 9800 0 0 3 700 15 0
> - 9800 0 0 4 700 16 0
> + 9800 0 0 1 700 17 2
> + 9800 0 0 2 700 14 2
> + 9800 0 0 3 700 15 2
> + 9800 0 0 4 700 16 2
> =20
> /* IDSEL 0x15 */
> - a800 0 0 1 700 14 0
> - a800 0 0 2 700 15 0
> - a800 0 0 3 700 16 0
> - a800 0 0 4 700 17 0
> + a800 0 0 1 700 14 2
> + a800 0 0 2 700 15 2
> + a800 0 0 3 700 16 2
> + a800 0 0 4 700 17 2
> =20
> /* IDSEL 0x16 */
> - b000 0 0 1 700 17 0
> - b000 0 0 2 700 14 0
> - b000 0 0 3 700 15 0
> - b000 0 0 4 700 16 0
> + b000 0 0 1 700 17 2
> + b000 0 0 2 700 14 2
> + b000 0 0 3 700 15 2
> + b000 0 0 4 700 16 2
> =20
> /* IDSEL 0x17 */
> - b800 0 0 1 700 16 0
> - b800 0 0 2 700 17 0
> - b800 0 0 3 700 14 0
> - b800 0 0 4 700 15 0
> + b800 0 0 1 700 16 2
> + b800 0 0 2 700 17 2
> + b800 0 0 3 700 14 2
> + b800 0 0 4 700 15 2
> =20
> /* IDSEL 0x18 */
> - b000 0 0 1 700 15 0
> - b000 0 0 2 700 16 0
> - b000 0 0 3 700 17 0
> - b000 0 0 4 700 14 0>;
> + b000 0 0 1 700 15 2
> + b000 0 0 2 700 16 2
> + b000 0 0 3 700 17 2
> + b000 0 0 4 700 14 2>;
> interrupt-parent =3D <700>;
> interrupts =3D <42 8>;
> bus-range =3D <0 0>;
> --
> 1.4.1
Where these IDSEL 0x15~0x18 come from on 8349EMDS board?
Please expain it.
-DAve
^ permalink raw reply
* Re: PPC 2.6.11.4 kernel panics while doing insmod (store fault with d cbst in icache_flush_range)
From: Paul Mackerras @ 2006-08-29 4:35 UTC (permalink / raw)
To: Kallol Biswas
Cc: Ronald Lee, linuxppc-dev, Radjendirane Codandaramane, Shawn Jin,
linux-kernel
In-Reply-To: <478F19F21671F04298A2116393EEC3D5540A32@sjc1exm08.pmc_nt.nt.pmc-sierra.bc.ca>
Kallol Biswas writes:
> mr r6,r3
> 1: dcbst 0,r3
> addi r3,r3,L1_CACHE_LINE_SIZE
> bdnz 1b
>
> The instruction takes a store fault (DST bit, bit 8 of ESR gets
> set), kernel panics with oops (signal 11).
What processor are you using?
Which instruction takes a store fault?
Paul.
^ permalink raw reply
* RE: PPC 2.6.11.4 kernel panics while doing insmod (store fault wi th d cbst in icache_flush_range)
From: Kallol Biswas @ 2006-08-29 4:59 UTC (permalink / raw)
To: 'Paul Mackerras'
Cc: Ronald Lee, linuxppc-dev, Radjendirane Codandaramane, Shawn Jin,
linux-kernel
Processor: PPC440
Dcbst takes the store fault.
-----Original Message-----
From: Paul Mackerras [mailto:paulus@samba.org]
Sent: Monday, August 28, 2006 9:35 PM
To: Kallol Biswas
Cc: linux-kernel@vger.kernel.org; linuxppc-dev@ozlabs.org; Ronald Lee; Radjendirane Codandaramane; Shawn Jin
Subject: Re: PPC 2.6.11.4 kernel panics while doing insmod (store fault with d cbst in icache_flush_range)
Kallol Biswas writes:
> mr r6,r3
> 1: dcbst 0,r3
> addi r3,r3,L1_CACHE_LINE_SIZE
> bdnz 1b
>
> The instruction takes a store fault (DST bit, bit 8 of ESR gets set),
> kernel panics with oops (signal 11).
What processor are you using?
Which instruction takes a store fault?
Paul.
^ permalink raw reply
* RE: atomic operations in user space
From: Li Yang-r58472 @ 2006-08-29 6:43 UTC (permalink / raw)
To: Xupei Liang, linuxppc-embedded
In-Reply-To: <20060829004336.97699.qmail@web36110.mail.mud.yahoo.com>
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
> Xupei Liang
> Sent: Tuesday, August 29, 2006 8:44 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: RE: atomic operations in user space
>=20
> I think it is less expensive using atomic operation
> sometimes in the user space, e.g. when updating a
Atomic operations are working under strict restrictions. Generally they
won't work for user space. Your best bet is to use semaphore instead.
> counter. If this counter is to be updated by a lot of
> processes, using semaphore can potentially cause a lot
> of task switching.
>=20
> Regards,
>=20
> Terry Liang
>=20
>=20
> > -----Original Message-----
> > From: Brent Cook [mailto:bcook at bpointsys.com]
> > Sent: Thursday, August 24, 2006 10:18 PM
> > To: linuxppc-embedded at ozlabs.org
> > Cc: Li Yang-r58472; Terry Liang
> > Subject: Re: atomic operations in user space
> >
> > On Thursday 24 August 2006 05:39, Li Yang-r58472
> wrote:
> >
> > > Why do you need atomic operations in user land?
> IPC will be
> sufficient
> >
> > > to deal with race conditions between processes.
> >
> > >
> >
> > > Best Regards,
> >
> > > Leo
> >
> > What about multiple threads within a process
> updating a counter?
>=20
> Is there anything preventing semaphore to be used in
> threads?
> >
> > Of course, if you look at these functions in the
> kernel header,
> they're just 2 or
> > 3 inline assembly calls - you could easily rewrite
> them. Google for
> 'PowerPC atomic
> > increment' and grab one of the unencumbered
> implementations if you
> need to use it
> > in a non-GPL program.
> >
> > On the other hand, I see no license at the top of my
> /usr/include/asm-i386/atomic.h
> > file at all, same for PowerPC - are Linux header
> files actually GPL or
> are they
> > more like the glibc headers, with exceptions made
> for userspace
> programs?
> >
> > The atomic operations on x86 were accidentally
> exported early on, so
> they have to
> > hang around apparently for compatibility (there are
> some mailing list
> threads out
> > there to this effect.) Currently, you just have to
> assume in Linux
> that if you
> > include something from /usr/include/linux or asm
> that it will not
> necessarily be
> > cross-version or cross-architecture compatible. Not
> every arch in
> Linux even has
> > atomic operations of this nature, which I guess is
> the main reason why
> they are
> > not exported in general.
> >
> > - Brent
>=20
>=20
>=20
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: Segher Boessenkool @ 2006-08-29 6:43 UTC (permalink / raw)
To: Willschm; +Cc: linuxppc-dev, Paul Mackerras, segher, arnd
In-Reply-To: <1156788215.5959.25.camel@localhost>
>> I just did a patch to fix the existing masks.
Thanks Paul.
>> Could you do a new
>> version of this patch that doesn't include the unrelated mask fixes
>> please? Also it would be really nice if you could figure out a
>> way to
>> avoid doing the unnecessary 64-bit logical operations on 32-bit
>> machines - i.e. using an unsigned long for tmp, but then the
>> constants
>> become problematic. Maybe you need something like
>>
>> #define LCONST(x) ((unsigned long)(x##ULL))
>
> Ok, how about this..
Hrm. The LCONST() thing is butt ugly though; you can just write
0x3333333333333333ULL etc. and GCC will do the right thing (i.e.
efficient code), and not warn (don't need the "ULL" even when in
C99/gnu99 mode, as we should be but aren't, heh).
You want to make tmp and unsigned long instead of an u64...
Segher
^ permalink raw reply
* Re: [PATCH] corrected PCI interrupt sense values to level low in mpc8349emds.dts
From: Paul Mackerras @ 2006-08-29 6:48 UTC (permalink / raw)
To: Kim Phillips; +Cc: linuxppc-dev
In-Reply-To: <20060828174910.236bf042.kim.phillips@freescale.com>
Kim Phillips writes:
> Corrected PCI interrupt sense values to level low in
> mpc8349emds.dts, per Leo's recommendation.
Please send an amended version of your original patch.
Thanks,
Paul.
^ permalink raw reply
* Re: copy_4K_page() doesn't use dcbtst?
From: Segher Boessenkool @ 2006-08-29 6:57 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Hollis Blanchard, xen-ppc-devel
In-Reply-To: <17651.34629.132793.190742@cargo.ozlabs.ibm.com>
> A stronger argument would be for using dcbz, but IIRC it actually made
> things slower (on POWER4 at least). I suspect the hardware is
> gathering the stores for the whole of each cache line automatically,
> so using dcbz doesn't provide any benefit.
It seems on 970 at least it still is a nice win. Do you have any
good benchmarks I could run?
> I did a lot of measurements of memory copy speed on POWER4 (using
> different copy loops, copy sizes, alignments, cache hot/cold cases)
> and the copy_4K_page loop is the fastest I could come up with for
> POWER4.
Yeah, POWER4 is quite a different beast (its memory subsystem,
anyway). I'm surprised dcbz hurt though; did you schedule it
early enough before the actual data copy?
Segher
^ permalink raw reply
* RE: atomic operations in user space
From: Esben Nielsen @ 2006-08-29 8:33 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: Xupei Liang, linuxppc-embedded
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC726@zch01exm20.fsl.freescale.net>
On Tue, 29 Aug 2006, Li Yang-r58472 wrote:
>> -----Original Message-----
>> From: linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org
>> [mailto:linuxppc-embedded-bounces+leoli=freescale.com@ozlabs.org] On
> Behalf Of
>> Xupei Liang
>> Sent: Tuesday, August 29, 2006 8:44 AM
>> To: linuxppc-embedded@ozlabs.org
>> Subject: RE: atomic operations in user space
>>
>> I think it is less expensive using atomic operation
>> sometimes in the user space, e.g. when updating a
>
> Atomic operations are working under strict restrictions. Generally they
> won't work for user space. Your best bet is to use semaphore instead.
>
Wrong.
1) Semaphores give priority inversions. Use a mutex with priority
inheritance instead. This comes in 2.6.18.
2) These mutexes are based on futexes which requires atomic operations in
userspace. These are available on most architectures. Look at the glibc code
in nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h forinstance.
Use that and your PPC manual to implement your atomic operations.
Esben
>> counter. If this counter is to be updated by a lot of
>> processes, using semaphore can potentially cause a lot
>> of task switching.
>>
>> Regards,
>>
>> Terry Liang
>>
>>
>>> -----Original Message-----
>>> From: Brent Cook [mailto:bcook at bpointsys.com]
>>> Sent: Thursday, August 24, 2006 10:18 PM
>>> To: linuxppc-embedded at ozlabs.org
>>> Cc: Li Yang-r58472; Terry Liang
>>> Subject: Re: atomic operations in user space
>>>
>>> On Thursday 24 August 2006 05:39, Li Yang-r58472
>> wrote:
>>>
>>>> Why do you need atomic operations in user land?
>> IPC will be
>> sufficient
>>>
>>>> to deal with race conditions between processes.
>>>
>>>>
>>>
>>>> Best Regards,
>>>
>>>> Leo
>>>
>>> What about multiple threads within a process
>> updating a counter?
>>
>> Is there anything preventing semaphore to be used in
>> threads?
>>>
>>> Of course, if you look at these functions in the
>> kernel header,
>> they're just 2 or
>>> 3 inline assembly calls - you could easily rewrite
>> them. Google for
>> 'PowerPC atomic
>>> increment' and grab one of the unencumbered
>> implementations if you
>> need to use it
>>> in a non-GPL program.
>>>
>>> On the other hand, I see no license at the top of my
>> /usr/include/asm-i386/atomic.h
>>> file at all, same for PowerPC - are Linux header
>> files actually GPL or
>> are they
>>> more like the glibc headers, with exceptions made
>> for userspace
>> programs?
>>>
>>> The atomic operations on x86 were accidentally
>> exported early on, so
>> they have to
>>> hang around apparently for compatibility (there are
>> some mailing list
>> threads out
>>> there to this effect.) Currently, you just have to
>> assume in Linux
>> that if you
>>> include something from /usr/include/linux or asm
>> that it will not
>> necessarily be
>>> cross-version or cross-architecture compatible. Not
>> every arch in
>> Linux even has
>>> atomic operations of this nature, which I guess is
>> the main reason why
>> they are
>>> not exported in general.
>>>
>>> - Brent
>>
>>
>>
>> __________________________________________________
>> Do You Yahoo!?
>> Tired of spam? Yahoo! Mail has the best spam protection around
>> http://mail.yahoo.com
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* RE: atomic operations in user space
From: Li Yang-r58472 @ 2006-08-29 8:54 UTC (permalink / raw)
To: Esben Nielsen; +Cc: Xupei Liang, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0608290946230.9162@frodo.shire>
> -----Original Message-----
> From: Esben Nielsen [mailto:nielsen.esben@gogglemail.com]
> Sent: Tuesday, August 29, 2006 4:33 PM
> To: Li Yang-r58472
> Cc: Xupei Liang; linuxppc-embedded@ozlabs.org
> Subject: RE: atomic operations in user space
>=20
>=20
>=20
> On Tue, 29 Aug 2006, Li Yang-r58472 wrote:
>=20
> >> -----Original Message-----
> >> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> >> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org]
On
> > Behalf Of
> >> Xupei Liang
> >> Sent: Tuesday, August 29, 2006 8:44 AM
> >> To: linuxppc-embedded@ozlabs.org
> >> Subject: RE: atomic operations in user space
> >>
> >> I think it is less expensive using atomic operation
> >> sometimes in the user space, e.g. when updating a
> >
> > Atomic operations are working under strict restrictions. Generally
they
> > won't work for user space. Your best bet is to use semaphore
instead.
> >
>=20
> Wrong.
> 1) Semaphores give priority inversions. Use a mutex with priority
> inheritance instead. This comes in 2.6.18.
> 2) These mutexes are based on futexes which requires atomic operations
in
> userspace. These are available on most architectures. Look at the
glibc code
> in nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h forinstance.
> Use that and your PPC manual to implement your atomic operations.
No matter semaphore or futex, it uses system calls to kernel. And the
true atomic operation is in kernel not user space. Maybe it's feasible
for other architectures to do atomic operations directly in user space.
IMHO, not for powerpc.
>=20
> Esben
>=20
> >> counter. If this counter is to be updated by a lot of
> >> processes, using semaphore can potentially cause a lot
> >> of task switching.
> >>
> >> Regards,
> >>
> >> Terry Liang
> >>
> >>
> >>> -----Original Message-----
> >>> From: Brent Cook [mailto:bcook at bpointsys.com]
> >>> Sent: Thursday, August 24, 2006 10:18 PM
> >>> To: linuxppc-embedded at ozlabs.org
> >>> Cc: Li Yang-r58472; Terry Liang
> >>> Subject: Re: atomic operations in user space
> >>>
> >>> On Thursday 24 August 2006 05:39, Li Yang-r58472
> >> wrote:
> >>>
> >>>> Why do you need atomic operations in user land?
> >> IPC will be
> >> sufficient
> >>>
> >>>> to deal with race conditions between processes.
> >>>
> >>>>
> >>>
> >>>> Best Regards,
> >>>
> >>>> Leo
> >>>
> >>> What about multiple threads within a process
> >> updating a counter?
> >>
> >> Is there anything preventing semaphore to be used in
> >> threads?
> >>>
> >>> Of course, if you look at these functions in the
> >> kernel header,
> >> they're just 2 or
> >>> 3 inline assembly calls - you could easily rewrite
> >> them. Google for
> >> 'PowerPC atomic
> >>> increment' and grab one of the unencumbered
> >> implementations if you
> >> need to use it
> >>> in a non-GPL program.
> >>>
> >>> On the other hand, I see no license at the top of my
> >> /usr/include/asm-i386/atomic.h
> >>> file at all, same for PowerPC - are Linux header
> >> files actually GPL or
> >> are they
> >>> more like the glibc headers, with exceptions made
> >> for userspace
> >> programs?
> >>>
> >>> The atomic operations on x86 were accidentally
> >> exported early on, so
> >> they have to
> >>> hang around apparently for compatibility (there are
> >> some mailing list
> >> threads out
> >>> there to this effect.) Currently, you just have to
> >> assume in Linux
> >> that if you
> >>> include something from /usr/include/linux or asm
> >> that it will not
> >> necessarily be
> >>> cross-version or cross-architecture compatible. Not
> >> every arch in
> >> Linux even has
> >>> atomic operations of this nature, which I guess is
> >> the main reason why
> >> they are
> >>> not exported in general.
> >>>
> >>> - Brent
> >>
> >>
> >>
> >> __________________________________________________
> >> Do You Yahoo!?
> >> Tired of spam? Yahoo! Mail has the best spam protection around
> >> http://mail.yahoo.com
> >> _______________________________________________
> >> Linuxppc-embedded mailing list
> >> Linuxppc-embedded@ozlabs.org
> >> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> > _______________________________________________
> > Linuxppc-embedded mailing list
> > Linuxppc-embedded@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >
^ permalink raw reply
* RE: atomic operations in user space
From: Liu Dave-r63238 @ 2006-08-29 9:20 UTC (permalink / raw)
To: Li Yang-r58472, Esben Nielsen; +Cc: Xupei Liang, linuxppc-embedded
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC774@zch01exm20.fsl.freescale.net>
> > 2) These mutexes are based on futexes which requires atomic=20
> > operations in userspace. These are available on most architectures.
Look at
> > the glibc code in
> > nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance.
> > Use that and your PPC manual to implement your atomic operations.
>=20
> No matter semaphore or futex, it uses system calls to kernel. And the
> true atomic operation is in kernel not user space. Maybe=20
> it's feasible
> for other architectures to do atomic operations directly in=20
> user space.
> IMHO, not for powerpc.
Are you meaning that we didn't do atomic operations directly in user
space
on powerpc platform ?
-DAve
^ permalink raw reply
* RE: atomic operations in user space
From: Esben Nielsen @ 2006-08-29 9:56 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: Esben Nielsen, Xupei Liang, linuxppc-embedded
In-Reply-To: <995B09A8299C2C44B59866F6391D263511BAE8@zch01exm21.fsl.freescale.net>
On Tue, 29 Aug 2006, Liu Dave-r63238 wrote:
>>> 2) These mutexes are based on futexes which requires atomic
>>> operations in userspace. These are available on most architectures.
> Look at
>>> the glibc code in
>>> nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance.
>>> Use that and your PPC manual to implement your atomic operations.
>>
>> No matter semaphore or futex, it uses system calls to kernel.
There is only a system call if there is congestion - that is the whole idea
behind the futex.
>> And the
>> true atomic operation is in kernel not user space.
"True" atomic operations are available in user space on most architectures.
>> Maybe
>> it's feasible
>> for other architectures to do atomic operations directly in
>> user space.
>> IMHO, not for powerpc.
It is available for PowerPC, but not in POWER and POWER2 instructionsets
according to http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
It is the same in the ARM world: Atomic instructions was introduced in
ARMv6 I believe. Older ARM processors don't have them.
>
> Are you meaning that we didn't do atomic operations directly in user
> space
> on powerpc platform ?
>
Well, that is not the conclusion I get either when reading the glibc code.
Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h.
This is by the way probably what the original post in this thread wanted
in the first place!
Esben
> -DAve
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* RE: atomic operations in user space
From: Liu Dave-r63238 @ 2006-08-29 10:05 UTC (permalink / raw)
To: Esben Nielsen; +Cc: Xupei Liang, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0608291136370.12461@frodo.shire>
> >>> 2) These mutexes are based on futexes which requires atomic=20
> >>> operations in userspace. These are available on most=20
> architectures.
> > Look at
> >>> the glibc code in
> >>> nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance.
> >>> Use that and your PPC manual to implement your atomic operations.
> >>
> >> No matter semaphore or futex, it uses system calls to kernel.
>=20
> There is only a system call if there is congestion - that is=20
> the whole idea behind the futex.
>=20
> >> And the
> >> true atomic operation is in kernel not user space.
>=20
> "True" atomic operations are available in user space on most=20
> architectures.
>=20
> >> Maybe
> >> it's feasible
> >> for other architectures to do atomic operations directly in user=20
> >> space.
> >> IMHO, not for powerpc.
>=20
> It is available for PowerPC, but not in POWER and POWER2=20
> instructionsets according to=20
> http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
> It is the same in the ARM world: Atomic instructions was introduced in
> ARMv6 I believe. Older ARM processors don't have them.
>=20
> >
> > Are you meaning that we didn't do atomic operations directly in user
> > space
> > on powerpc platform ?
> >
>=20
> Well, that is not the conclusion I get either when reading=20
> the glibc code.
> Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h.
>=20
> This is by the way probably what the original post in this=20
> thread wanted=20
> in the first place!
>=20
> Esben
I totally agree with you and Brant about it. I don't believe we cannot
do the atomic operation in user space on powerpc.
-DAve=20
^ permalink raw reply
* RE: atomic operations in user space
From: Li Yang-r58472 @ 2006-08-29 10:52 UTC (permalink / raw)
To: Esben Nielsen, Liu Dave-r63238; +Cc: Xupei Liang, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0608291136370.12461@frodo.shire>
> -----Original Message-----
> From: Esben Nielsen [mailto:nielsen.esben@gogglemail.com]
> Sent: Tuesday, August 29, 2006 5:57 PM
> To: Liu Dave-r63238
> Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang;
linuxppc-embedded@ozlabs.org
> Subject: RE: atomic operations in user space
>=20
>=20
>=20
> On Tue, 29 Aug 2006, Liu Dave-r63238 wrote:
>=20
> >>> 2) These mutexes are based on futexes which requires atomic
> >>> operations in userspace. These are available on most
architectures.
> > Look at
> >>> the glibc code in
> >>> nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance.
> >>> Use that and your PPC manual to implement your atomic operations.
> >>
> >> No matter semaphore or futex, it uses system calls to kernel.
>=20
> There is only a system call if there is congestion - that is the whole
idea
> behind the futex.
>=20
> >> And the
> >> true atomic operation is in kernel not user space.
>=20
> "True" atomic operations are available in user space on most
architectures.
>=20
> >> Maybe
> >> it's feasible
> >> for other architectures to do atomic operations directly in
> >> user space.
> >> IMHO, not for powerpc.
>=20
> It is available for PowerPC, but not in POWER and POWER2
instructionsets
> according to http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
> It is the same in the ARM world: Atomic instructions was introduced in
> ARMv6 I believe. Older ARM processors don't have them.
Yes, I do know there are lwarx and stwrx instructions. But there is
only one reservation per CPU and reservation can be re-established with
no difference.
So there are possibilities reservation is broken and reserved again in
one atomic block.
Task A Task B
lwarx
......
lwarx
stwrx
.....
.....
lwarx
stwrx
.....
stwrx
The addresses of above operations are the same.
In this case Thread A thinks that it is atomic as it holds the same
reservation, but it is actually broken. Such control flow can't be
prevented in user space.
>=20
> >
> > Are you meaning that we didn't do atomic operations directly in user
> > space
> > on powerpc platform ?
> >
>=20
> Well, that is not the conclusion I get either when reading the glibc
code.
> Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h.
>=20
> This is by the way probably what the original post in this thread
wanted
> in the first place!
>=20
> Esben
>=20
>=20
> > -DAve
^ permalink raw reply
* RE: atomic operations in user space
From: Esben Nielsen @ 2006-08-29 11:26 UTC (permalink / raw)
To: Li Yang-r58472
Cc: Esben Nielsen, Xupei Liang, Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC7A3@zch01exm20.fsl.freescale.net>
On Tue, 29 Aug 2006, Li Yang-r58472 wrote:
>
>> -----Original Message-----
>> From: Esben Nielsen [mailto:nielsen.esben@gogglemail.com]
>> Sent: Tuesday, August 29, 2006 5:57 PM
>> To: Liu Dave-r63238
>> Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang;
> linuxppc-embedded@ozlabs.org
>> Subject: RE: atomic operations in user space
>>
>>
>>
>> On Tue, 29 Aug 2006, Liu Dave-r63238 wrote:
>>
>>>>> 2) These mutexes are based on futexes which requires atomic
>>>>> operations in userspace. These are available on most
> architectures.
>>> Look at
>>>>> the glibc code in
>>>>> nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance.
>>>>> Use that and your PPC manual to implement your atomic operations.
>>>>
>>>> No matter semaphore or futex, it uses system calls to kernel.
>>
>> There is only a system call if there is congestion - that is the whole
> idea
>> behind the futex.
>>
>>>> And the
>>>> true atomic operation is in kernel not user space.
>>
>> "True" atomic operations are available in user space on most
> architectures.
>>
>>>> Maybe
>>>> it's feasible
>>>> for other architectures to do atomic operations directly in
>>>> user space.
>>>> IMHO, not for powerpc.
>>
>> It is available for PowerPC, but not in POWER and POWER2
> instructionsets
>> according to http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
>> It is the same in the ARM world: Atomic instructions was introduced in
>> ARMv6 I believe. Older ARM processors don't have them.
>
> Yes, I do know there are lwarx and stwrx instructions. But there is
> only one reservation per CPU and reservation can be re-established with
> no difference.
> So there are possibilities reservation is broken and reserved again in
> one atomic block.
>
> Task A Task B
> lwarx
> ......
> lwarx
> stwrx
>
> .....
> .....
> lwarx
> stwrx
> .....
> stwrx
>
> The addresses of above operations are the same.
>
> In this case Thread A thinks that it is atomic as it holds the same
> reservation, but it is actually broken. Such control flow can't be
> prevented in user space.
>
So you are saying that futexes on powerpc are broken?
Esben
>>
>>>
>>> Are you meaning that we didn't do atomic operations directly in user
>>> space
>>> on powerpc platform ?
>>>
>>
>> Well, that is not the conclusion I get either when reading the glibc
> code.
>> Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h.
>>
>> This is by the way probably what the original post in this thread
> wanted
>> in the first place!
>>
>> Esben
>>
>>
>>> -DAve
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* RE: atomic operations in user space
From: Esben Nielsen @ 2006-08-29 11:30 UTC (permalink / raw)
To: Esben Nielsen; +Cc: Xupei Liang, Liu Dave-r63238, linuxppc-embedded
In-Reply-To: <Pine.LNX.4.64.0608291323390.12461@frodo.shire>
On Tue, 29 Aug 2006, Esben Nielsen wrote:
>
>
> On Tue, 29 Aug 2006, Li Yang-r58472 wrote:
>
>>
>> > -----Original Message-----
>> > From: Esben Nielsen [mailto:nielsen.esben@gogglemail.com]
>> > Sent: Tuesday, August 29, 2006 5:57 PM
>> > To: Liu Dave-r63238
>> > Cc: Li Yang-r58472; Esben Nielsen; Xupei Liang;
>> linuxppc-embedded@ozlabs.org
>> > Subject: RE: atomic operations in user space
>> >
>> >
>> >
>> > On Tue, 29 Aug 2006, Liu Dave-r63238 wrote:
>> >
>> > > > > 2) These mutexes are based on futexes which requires atomic
>> > > > > operations in userspace. These are available on most
>> architectures.
>> > > Look at
>> > > > > the glibc code in
>> > > > > nptl/sysdeps/unix/sysv/linux/powerpc/lowlevellock.h for instance.
>> > > > > Use that and your PPC manual to implement your atomic operations.
>> > > >
>> > > > No matter semaphore or futex, it uses system calls to kernel.
>> >
>> > There is only a system call if there is congestion - that is the whole
>> idea
>> > behind the futex.
>> >
>> > > > And the
>> > > > true atomic operation is in kernel not user space.
>> >
>> > "True" atomic operations are available in user space on most
>> architectures.
>> >
>> > > > Maybe
>> > > > it's feasible
>> > > > for other architectures to do atomic operations directly in
>> > > > user space.
>> > > > IMHO, not for powerpc.
>> >
>> > It is available for PowerPC, but not in POWER and POWER2
>> instructionsets
>> > according to http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
>> > It is the same in the ARM world: Atomic instructions was introduced in
>> > ARMv6 I believe. Older ARM processors don't have them.
>>
>> Yes, I do know there are lwarx and stwrx instructions. But there is
>> only one reservation per CPU and reservation can be re-established with
>> no difference.
>> So there are possibilities reservation is broken and reserved again in
>> one atomic block.
>>
>> Task A Task B
>> lwarx
>> ......
>> lwarx
>> stwrx
>>
>> .....
>> .....
>> lwarx
>> stwrx
>> .....
>> stwrx
>>
>> The addresses of above operations are the same.
>>
>> In this case Thread A thinks that it is atomic as it holds the same
>> reservation, but it is actually broken. Such control flow can't be
>> prevented in user space.
>>
>
> So you are saying that futexes on powerpc are broken?
Are you sure the reservation isn't automaticly broken due to the task
switch?
>
> Esben
>
Esben
>> >
>> > >
>> > > Are you meaning that we didn't do atomic operations directly in user
>> > > space
>> > > on powerpc platform ?
>> > >
>> >
>> > Well, that is not the conclusion I get either when reading the glibc
>> code.
>> > Try to look at glibc-2.3.5/sysdeps/powerpc/bits/atomic.h.
>> >
>> > This is by the way probably what the original post in this thread
>> wanted
>> > in the first place!
>> >
>> > Esben
>> >
>> >
>> > > -DAve
>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>
>
^ permalink raw reply
* RE: atomic operations in user space
From: Brent Cook @ 2006-08-29 12:36 UTC (permalink / raw)
To: Li Yang-r58472, Esben Nielsen, Liu Dave-r63238
Cc: Xupei Liang, linuxppc-embedded
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D0FC7A3@zch01exm20.fsl.freescale.net>
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+bcook=3Dbpointsys.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+bcook=3Dbpointsys.com@ozlabs.o
rg] On Behalf Of Li Yang-r58472
> Sent: Tuesday, August 29, 2006 5:53 AM
> To: Esben Nielsen; Liu Dave-r63238
> Cc: Xupei Liang; linuxppc-embedded@ozlabs.org
> Subject: RE: atomic operations in user space
>=20
> > It is available for PowerPC, but not in POWER and POWER2
> instructionsets
> > according to=20
> http://www.nersc.gov/vendor_docs/ibm/asm/lwarx.htm#idx607
> > It is the same in the ARM world: Atomic instructions was=20
> introduced in
> > ARMv6 I believe. Older ARM processors don't have them.
>=20
> Yes, I do know there are lwarx and stwrx instructions. But=20
> there is only one reservation per CPU and reservation can be=20
> re-established with no difference.
> So there are possibilities reservation is broken and reserved=20
> again in one atomic block.
>=20
> Task A Task B
> lwarx
> ......
> lwarx
> stwrx
>=20
> .....
> .....
> lwarx
> stwrx
> .....
> stwrx
>=20
> The addresses of above operations are the same.
>=20
> In this case Thread A thinks that it is atomic as it holds=20
> the same reservation, but it is actually broken. Such=20
> control flow can't be prevented in user space.
>=20
This is exactly how it is supposed to work! That's why there is a loop
in the atomic increment - you check if you still had the reservation
after the transaction by checking the result from the stwcx, and if not,
retry. This works perfectly well no matter if it is from userspace or
the kernel - it is a CPU function. It even works between CPUs on some
later PowerPCs - I've had it working perfectly from userspace on a dual
7448 setup.
PowerPC atomic instructions are not atomic in the sense that they _lock_
anything. The only thing these instructions give you is a way to see if
another thread used the instructions while your thread was using them,
and if you see a conflict, you retry until your code finishes
uninterrupted. This makes it fine for short transactions, like atomic
increment. You probably would not want to use these instructions for
protecting longer transactions of more than a few instructions.
If you look at how, for instance, futexes work in Linux, they rely on
being able to do atomic increment and decrement from _userspace_.
Read this article to understand how it works:
http://www-128.ibm.com/developerworks/library/pa-atom/
- Brent
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox