* Re: [1/5] powerpc: Fix handling of DSCR related facility unavailable exception
From: Anton Blanchard @ 2014-12-18 5:10 UTC (permalink / raw)
To: Anshuman Khandual; +Cc: mikey, linuxppc-dev
In-Reply-To: <5486F607.6010706@linux.vnet.ibm.com>
Hi Anshuman,
> Yeah I wanted to convert all these tests which are related to DSCR
> into individual self tests for powerpc. All these test cases have
> Anton Blanchard and IBM's copyright on it but they are licensed with
> GPL V2. Not sure whether Anton needs to okay this before I can modify
> them for self tests, put his (Anton's) signed-off-by and then post it
> in the mailing list.
>
> (1) http://ozlabs.org/~anton/junkcode/dscr_default_test.c
> (2) http://ozlabs.org/~anton/junkcode/dscr_explicit_test.c
> (3) http://ozlabs.org/~anton/junkcode/dscr_inherit_exec_test.c
> (4) http://ozlabs.org/~anton/junkcode/dscr_inherit_test.c
> (5) http://ozlabs.org/~anton/junkcode/user_dscr_test.c
I'm happy for the testcases to be modified and merged into the kernel!
When you submit them I'll give them a once over and attach my
Signed-off-by.
Thanks,
Anton
^ permalink raw reply
* RE: [RFC PATCH 0/2] powerpc: CR based local atomic operation implementation
From: Rusty Russell @ 2014-12-18 4:18 UTC (permalink / raw)
To: David Laight, 'Madhavan Srinivasan', mpe@ellerman.id.au
Cc: linuxppc-dev@lists.ozlabs.org, paulus@samba.org, anton@samba.org
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1C9FFB90@AcuExch.aculab.com>
David Laight <David.Laight@ACULAB.COM> writes:
> From: Madhavan Srinivasan [mailto:maddy@linux.vnet.ibm.com]
> ...
>> >>> I also wonder if it is possible to inspect the interrupted
>> >>> code to determine the start/end of the RAS block.
>> >>> (Easiest if you assume that there is a single 'write' instruction
>> >>> as the last entry in the block.)
>> >>>
>> >> So each local_* function also have code in the __ex_table section. IIUC,
>> >> __ex_table contains two address. So if the return address found in the
>> >> first column of the _ex_table, use the corresponding address in the
>> >> second column to continue from.
>> >
>> > That really doesn't scale.
>> > I don't know how many 1000 address pairs you table will have (and the
>> > ones in each loadable module), but the search isn't going to be cheap.
>> >
>> > If these sequences are restartable then they can only have one write
>> > to memory.
>> >
>>
>> May be, but i see these issues incase of insts decode path,
>>
>> 1) Decoding instruction may also cause a fault (in case of module) and
>> handling a fault at this stage toward the exit path of interrupt exit
>> makes me nervous
>
> It shouldn't be possible to unload a module that is interrupted by
> a hardware interrupt.
> An 'invalid' loadable module can cause an oops/panic anyway.
Yes, the module won't fault (vmalloc memory can be lazily mapped, but
we've already copied the module into there, so it won't happen).
>> 2) resulting code with lot of condition and branch (for opcode decode)
>> will be lot messy and may be an issue incase of maintenance,
>
> You don't need to decode the instructions.
> Just look for the two specific instructions used as markers.
> This is only really possible with fixed-size instructions.
>
> It might also be that the 'interrupt entry' path is easier to
> modify than the 'interrupt exit' one (fewer code paths) and
> you just need to modify the 'pc' in the stack frame.
> You are only interested in interrupts from kernel space.
It's an overoptimization for case that statistically never happens.
You won't even be able to measure the difference.
The question of bloat remains, but that's also easily measured. In
practice, I'd guess less than 1k.
Cheers,
Rusty.
^ permalink raw reply
* Re: [v2 PATCH 2/2] powerpc/8xx: use _PAGE_RO instead of _PAGE_RW
From: Scott Wood @ 2014-12-18 2:22 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <20141217091432.072901A5E12@localhost.localdomain>
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
> On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages
> and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> ---
> v2 is a complete rework compared to v1
>
> arch/powerpc/include/asm/pte-8xx.h | 7 +++----
> arch/powerpc/kernel/head_8xx.S | 3 ---
> 2 files changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
> index daa4616..4f5583e 100644
> --- a/arch/powerpc/include/asm/pte-8xx.h
> +++ b/arch/powerpc/include/asm/pte-8xx.h
> @@ -46,7 +46,7 @@
> * require a TLB exception handler change. It is assumed unused bits
> * are always zero.
> */
> -#define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */
> +#define _PAGE_RO 0x0400 /* lsb PP bits */
It looks like pte_update() needs to be updated to match.
> #define _PAGE_USER 0x0800 /* msb PP bits */
> /* set when neither _PAGE_USER nor _PAGE_RW are set */
Also update this comment.
> #define _PAGE_KNLRO 0x0200
> @@ -62,9 +62,8 @@
> #define PTE_ATOMIC_UPDATES 1
>
> /* We need to add _PAGE_SHARED to kernel pages */
> -#define _PAGE_KERNEL_RO (_PAGE_SHARED | _PAGE_KNLRO)
> -#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_KNLRO)
> -#define _PAGE_KERNEL_RW (_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE)
> +#define _PAGE_KERNEL_RO (_PAGE_SHARED | _PAGE_RO | _PAGE_KNLRO)
> +#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_RO | _PAGE_KNLRO)
>
> #endif /* __KERNEL__ */
> #endif /* _ASM_POWERPC_PTE_8xx_H */
Where did _PAGE_KERNEL_RW go?
-Scott
^ permalink raw reply
* Re: [v2 PATCH 1/2] powerpc32: adds handling of _PAGE_RO
From: Scott Wood @ 2014-12-18 2:14 UTC (permalink / raw)
To: Christophe Leroy; +Cc: linux-kernel, Paul Mackerras, linuxppc-dev
In-Reply-To: <20141217091431.D3F761A5E0D@localhost.localdomain>
On Wed, 2014-12-17 at 10:14 +0100, Christophe Leroy wrote:
> Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only) bit.
> This patch implements the handling of a _PAGE_RO flag to be used in place of _PAGE_RW
>
> Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
>
> ---
> v2 is a complete rework compared to v1
>
> arch/powerpc/include/asm/pgtable-ppc32.h | 11 ++++++-----
> arch/powerpc/include/asm/pgtable.h | 10 +++++++---
> arch/powerpc/include/asm/pte-common.h | 27 ++++++++++++++++++---------
> arch/powerpc/mm/gup.c | 2 ++
> arch/powerpc/mm/mem.c | 2 +-
> arch/powerpc/mm/pgtable_32.c | 24 ++++++++++++++++++++----
> 6 files changed, 54 insertions(+), 22 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h
> index 543bb8e..64ed9e1 100644
> --- a/arch/powerpc/include/asm/pgtable-ppc32.h
> +++ b/arch/powerpc/include/asm/pgtable-ppc32.h
> @@ -125,7 +125,7 @@ extern int icache_44x_need_flush;
> #ifndef __ASSEMBLY__
>
> #define pte_clear(mm, addr, ptep) \
> - do { pte_update(ptep, ~_PAGE_HASHPTE, 0); } while (0)
> + do { pte_update(ptep, ~_PAGE_HASHPTE, _PAGE_RO); } while (0)
Is this really necessary? It's already clearing the valid bit.
Likewise in several other places that set or check for _PAGE_RO on pages
for which no access is permitted.
> @@ -287,8 +287,9 @@ static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
> static inline void __ptep_set_access_flags(pte_t *ptep, pte_t entry)
> {
> unsigned long bits = pte_val(entry) &
> - (_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_EXEC);
> - pte_update(ptep, 0, bits);
> + (_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_RO |
> + _PAGE_EXEC);
> + pte_update(ptep, _PAGE_RO, bits);
> }
You're unconditionally clearing _PAGE_RO, and apparently relying on the
undocumented behavior of pte_update() to clear "clr" before setting
"set".
Instead I'd write this as:
unsigned long set = pte_val(entry) &
(_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_EXEC);
unsigned long clr = pte_val(entry) & _PAGE_RO;
pte_update(ptep, clr, set);
-Scott
^ permalink raw reply
* [PATCH] powerpc/mpc85xx: Add ranges to etsec2 nodes
From: Scott Wood @ 2014-12-18 1:06 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Scott Wood, Alexander Graf
Commit 746c9e9f92dd "of/base: Fix PowerPC address parsing hack" limited
the applicability of the workaround whereby a missing ranges is treated
as an empty ranges. This workaround was hiding a bug in the etsec2
device tree nodes, which have children with reg, but did not have
ranges.
Signed-off-by: Scott Wood <scottwood@freescale.com>
Reported-by: Alexander Graf <agraf@suse.de>
---
arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi | 1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi | 1 +
arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
index 1382fec..7fcb1ac 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-0.dtsi
@@ -50,6 +50,7 @@ ethernet@b0000 {
fsl,num_tx_queues = <0x8>;
fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
+ ranges;
queue-group@b0000 {
#address-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
index 221cd2e..9f25427 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-1.dtsi
@@ -50,6 +50,7 @@ ethernet@b1000 {
fsl,num_tx_queues = <0x8>;
fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
+ ranges;
queue-group@b1000 {
#address-cells = <1>;
diff --git a/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi b/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
index 61456c3..cd7c318 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-etsec2-2.dtsi
@@ -49,6 +49,7 @@ ethernet@b2000 {
fsl,num_tx_queues = <0x8>;
fsl,magic-packet;
local-mac-address = [ 00 00 00 00 00 00 ];
+ ranges;
queue-group@b2000 {
#address-cells = <1>;
--
2.1.0
^ permalink raw reply related
* Re: [PATCH v2 1/3] powerpc/nvram: move generic code for nvram and pstore
From: Hari Bathini @ 2014-12-17 11:10 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Mahesh J Salgaonkar
In-Reply-To: <1418774597.17248.1.camel@ellerman.id.au>
On 12/17/2014 05:33 AM, Michael Ellerman wrote:
> On Tue, 2014-12-16 at 23:35 +0530, Hari Bathini wrote:
>> With minor checks, we can move most of the code for nvram
>> under pseries to a common place to be re-used by other
>> powerpc platforms like powernv. This patch moves such
>> common code to arch/powerpc/kernel/nvram_64.c file.
> Sharing the code is great.
>
> But, you need to keep in mind that it is very common for us to build kernels
> with both POWERNV=y and PSERIES=y.
>
> So you need to make sure you're only using CONFIG_PPC_PSERIES to protect things
> that are optional on pseries. Not things that we *shouldn't* be doing on
> powernv.
>
> For example the logic in nvram_init_oops_partition() looks like it might do the
> wrong thing for PSERIES=y POWERNV=y.
True. It might do wrong thing when an incorrect value is passed by the
caller.
But since the caller is platform specific code
[pseries_nvram_init_log_partitions() or
opal_nvram_init_log_partitions() routine], with appropriate parameter
passed,
I haven't seen any issues while testing.
>> diff --git a/arch/powerpc/include/asm/rtas.h b/arch/powerpc/include/asm/rtas.h
>> index b390f55..a033fe9 100644
>> --- a/arch/powerpc/include/asm/rtas.h
>> +++ b/arch/powerpc/include/asm/rtas.h
>> @@ -343,6 +343,8 @@ extern int early_init_dt_scan_rtas(unsigned long node,
>> extern void pSeries_log_error(char *buf, unsigned int err_type, int fatal);
>>
>> #ifdef CONFIG_PPC_PSERIES
>> +extern unsigned long last_rtas_event;
>> +extern int clobbering_unread_rtas_event(void);
> You should add an empty version of this for !PSERIES, so you don't have to
> ifdef all the call sites.
Sure. Will update accordingly..
Thanks
Hari
> cheers
>
>
^ permalink raw reply
* [PATCH v2 2/4] powerpc/vphn: move endianness fixing to vphn_unpack_associativity()
From: Greg Kurz @ 2014-12-17 9:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20141217094007.16957.70423.stgit@bahia.local>
The first argument to vphn_unpack_associativity() is a const long *, but the
parsing code expects __be64 values actually. Let's move the endian fixing
down for consistency.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
v2: only move the endian fixing. The logic is reworked in another patch.
arch/powerpc/mm/numa.c | 10 ++++++----
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 2a83e48..2e36a6f 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1263,13 +1263,18 @@ static int update_cpu_associativity_changes_mask(void)
*/
static int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
{
+ __be64 be_packed[VPHN_REGISTER_COUNT];
int i, nr_assoc_doms = 0;
- const __be16 *field = (const __be16 *) packed;
+ const __be16 *field = (const __be16 *) be_packed;
#define VPHN_FIELD_UNUSED (0xffff)
#define VPHN_FIELD_MSB (0x8000)
#define VPHN_FIELD_MASK (~VPHN_FIELD_MSB)
+ /* Let's recreate the original stream. */
+ for (i = 0; i < VPHN_REGISTER_COUNT; i++)
+ be_packed[i] = cpu_to_be64(packed[i]);
+
for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
if (be16_to_cpup(field) == VPHN_FIELD_UNUSED) {
/* All significant fields processed, and remaining
@@ -1310,11 +1315,8 @@ static long hcall_vphn(unsigned long cpu, __be32 *associativity)
long retbuf[PLPAR_HCALL9_BUFSIZE] = {0};
u64 flags = 1;
int hwcpu = get_hard_smp_processor_id(cpu);
- int i;
rc = plpar_hcall9(H_HOME_NODE_ASSOCIATIVITY, retbuf, flags, hwcpu);
- for (i = 0; i < VPHN_REGISTER_COUNT; i++)
- retbuf[i] = cpu_to_be64(retbuf[i]);
vphn_unpack_associativity(retbuf, associativity);
return rc;
^ permalink raw reply related
* Re: PROBLEM: USB isochronous urb leak on EHCI driver
From: Alan Stern @ 2014-12-17 16:40 UTC (permalink / raw)
To: Michael Tessier; +Cc: linuxppc-dev@lists.ozlabs.org, linux-usb@vger.kernel.org
In-Reply-To: <66A26A9AA227D947AF088537F041526E1FF44F@VSVR-EX10-MB1.pocatec.com>
On Mon, 15 Dec 2014, Michael Tessier wrote:
> Hi,
>
> I am dealing with a USB EHCI driver bug. Here is the info:
>
> My configuration:
> -----------------
>
> Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller)
> Linux kernel: 2.6.31, using EHCI USB driver
As mentioned by other people, the age of that kernel makes any bug
report completely irrelevant. It's hard to count the number of
non-trivial changes that have been made to the isochronous code in
ehci-hcd since 2.6.31, but there have been quite a few.
> Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b)
> Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901)
>
> Note: each codec is being used in R/W access, so with 4 codecs, I have
> 4 playback and 4 capture streams.
>
> My problem:
> -----------
>
> I have usb urb leaks when connecting more than 1 codec to the USB 1.1
> Hub.
What do you mean by "urb leak"? Normally, people use the word "leak"
to refer to memory that is dynamically allocated and never deallocated,
but you seem to mean something else.
> (the result is that some of the audio data is not transferred,
> part of the sound is simply missing) No problem when using only 1
> of the 4 codecs connected to the hub; When I connect a second codec,
> the sound quality starts to degrade. With 3 codecs, we just cannot
> recognize a speach.
>
> Tests and observations:
> -----------------------
>
> Since I have 3 usb ports available on the i.MX512, I tried to connect
> 3 codecs directly on USB ports: the sound is perfect on each of the
> three ports.
>
> I bought a consumer USB 2.0 Hub: no problem when using 3 codecs
> connected to that Hub, however, the audio will completly stop on all
> channels when connecting the 4th codec.
Above you said the sound started to degrade when the second codec was
connected; here you say there is no problem when using 3 of them.
Which is it? Do you mean that the high-speed hub works better than the
full-speed hub?
> I checked the communication between the Hub (USB 1.1) and the Host
> controller (USB 2.0) with a scope and concluded that the
> communication speed is 1.5 MBytes/s has expected (so the
> communication is downgraded to USB 1.1, since codecs and hub are USB
> 1.1 devices).
>
> Also, I know that there is physically enough bandwidth to
> transfer the data for two reasons:
> 1) I have an older CPU with a USB 1.1 host controller (using the OHCI
> driver), using the same hub and the same codecs: works like a champ,
> using less than 50% of the available bandwidth (observed with a
> scope)
> 2) 1 audio stream is 32khz-mono, 16 bits = 64 kB/s,
> 4 codecs = 8 streams(R/W) x 64 kB/s = 512 kB/s (out of 1.5MB/s)
The amount of bandwidth available is usually not as much of an issue as
the ability of the scheduling alogorithm to divide the bandwidth among
the streams. The algorithm is not very smart and it often runs into a
wall even when lots of physical bandwidth is still available.
> I noticed that my sound problem starts happening with only 2 codecs
> (4 streams, 256 kB/s). I first thought that it was a bandwidth
> limitation, so I decided to connect only 1 codec using more bandwidth.
> I configured it to 48khz-stereo (16-bits), using 384 kB/s for both
> read and write streams: no problem. With that configuration, the
> scope shows about 30% of total bandwidth usage (300us used out of 1ms
> periods). Then, I added a second codec (48khz-stereo-16bits): very
> strange, now the total bandwidth usage felt down to about 200us, which
> seems to keep the same, whatever the number of codec I add (I also
> tried 3 and 4...). So it looks like the scheduler is not able to
> properly allocate Isochronous time slots when more than one device is
> connected to the hub. However, without the hub, it works perfectly.
How does your hardware connect the host controller to a full-speed
device? Is there an internal hub (Intel motherboards have used this
approach)? Is there a companion USB-1.1 controller (older motherboards
from Intel and other companys have used this approach)? Does the EHCI
controller have a built-in Transaction Translator (some SOC systems use
this approach)?
> Another interresting fact is that at application level, the Read and
> Write operations are returning the good amount of bytes read/written.
> This is not the case at kernel level: I noticed that function
> "usb_submit_urb" (from /drivers/usb/core/urb.c) will only tranfer
> part of the "urbs" when the sound is degraded. I tried to figure out
> where the leak comes from without success. Also, there are no error
> messages from kernel so everything appears to work well, excepted
> that part of the sound is missing!
>
> I can't change my hardware (this is in the hand of customers), so
> the only possible solution for me is to correct the software.
>
> I tried to change my ehci driver with the one from kernel 2.6.39.4
> but did not work, same problem.
>
> Question:
> ---------
>
> Before attempting to upgrade to an earlier kernel driver (this is
"upgrade to an earlier kernel driver" is a contradiction in terms.
Moving to an earlier driver would be a _downgrade_.
> a fairly big amount of work), I would really like to know if this
> problem would still be in the 3.x kernels. Has anyone seen that
> issue in 3.x kernels?
It depends a lot on the system hardware. Many people are using USB
audio in 3.x kernels with no problem. On the other hand, some people
have reported a bug (quite different from yours) so recently that the
patch to fix it has not yet been merged.
> I am pretty new to USB driver debugging, so any ideas of where/how
> to find solutions will be appreciated. Thank you very much in advance
> for the support. Also don't hesitate to redirect me if I'm not at the
> right place to ask these questions. I can also provide some code if
> someone need it to help.
Your first step should be to use an up-to-date kernel, as recommended
by other people.
Alan Stern
^ permalink raw reply
* [PATCH v2 4/4] powerpc/vphn: parsing code rewrite
From: Greg Kurz @ 2014-12-17 9:43 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20141217094007.16957.70423.stgit@bahia.local>
The current VPHN parsing logic has some flaws that this patch aims to fix:
1) when the value 0xffff is read, the value 0xffffffff gets added to the
the output list and its element count isn't incremented. This is wrong.
According to PAPR+ the domain identifiers are packed into a sequence
terminated by the "reserved value of all ones". This means that 0xffff
is a stream terminator.
2) the combination of byteswaps and casts make the code hardly readable.
Let's parse the stream one 16-bit field at a time instead.
3) it is assumed that the hypercall returns 12 32-bit values packed into
6 64-bit registers. According to PAPR+, the domain identifiers may be
streamed as 16-bit values. Let's increase the number of expected numbers
to 24.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
arch/powerpc/mm/vphn.c | 54 +++++++++++++++++++++++++++++++++---------------
arch/powerpc/mm/vphn.h | 6 +++--
2 files changed, 40 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/mm/vphn.c b/arch/powerpc/mm/vphn.c
index c49ed51..5f8ef50 100644
--- a/arch/powerpc/mm/vphn.c
+++ b/arch/powerpc/mm/vphn.c
@@ -2,44 +2,64 @@
#include "vphn.h"
/*
- * Convert the associativity domain numbers returned from the hypervisor
- * to the sequence they would appear in the ibm,associativity property.
+ * The associativity domain numbers are returned from the hypervisor as a
+ * stream of mixed 16-bit and 32-bit fields. The stream is terminated by the
+ * special value of "all ones" (aka. 0xffff) and its size may not exceed 48
+ * bytes.
+ *
+ * --- 16-bit fields -->
+ * _________________________
+ * | 0 | 1 | 2 | 3 | be_packed[0]
+ * ------+-----+-----+------
+ * _________________________
+ * | 4 | 5 | 6 | 7 | be_packed[1]
+ * -------------------------
+ * ...
+ * _________________________
+ * | 20 | 21 | 22 | 23 | be_packed[5]
+ * -------------------------
+ *
+ * Convert to the sequence they would appear in the ibm,associativity property.
*/
int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
{
__be64 be_packed[VPHN_REGISTER_COUNT];
int i, nr_assoc_doms = 0;
const __be16 *field = (const __be16 *) be_packed;
+ u16 last = 0;
+ bool is_32bit = false;
#define VPHN_FIELD_UNUSED (0xffff)
#define VPHN_FIELD_MSB (0x8000)
#define VPHN_FIELD_MASK (~VPHN_FIELD_MSB)
- /* Let's recreate the original stream. */
+ /* Let's fix the values returned by plpar_hcall9() */
for (i = 0; i < VPHN_REGISTER_COUNT; i++)
be_packed[i] = cpu_to_be64(packed[i]);
for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
- if (be16_to_cpup(field) == VPHN_FIELD_UNUSED) {
- /* All significant fields processed, and remaining
- * fields contain the reserved value of all 1's.
- * Just store them.
+ u16 new = be16_to_cpup(field++);
+
+ if (is_32bit) {
+ /* Let's concatenate the 16 bits of this field to the
+ * 15 lower bits of the previous field
*/
- unpacked[i] = *((__be32 *)field);
- field += 2;
- } else if (be16_to_cpup(field) & VPHN_FIELD_MSB) {
+ unpacked[++nr_assoc_doms] =
+ cpu_to_be32(last << 16 | new);
+ is_32bit = false;
+ } else if (new == VPHN_FIELD_UNUSED)
+ /* This is the list terminator */
+ break;
+ else if (new & VPHN_FIELD_MSB) {
/* Data is in the lower 15 bits of this field */
- unpacked[i] = cpu_to_be32(
- be16_to_cpup(field) & VPHN_FIELD_MASK);
- field++;
- nr_assoc_doms++;
+ unpacked[++nr_assoc_doms] =
+ cpu_to_be32(new & VPHN_FIELD_MASK);
} else {
/* Data is in the lower 15 bits of this field
* concatenated with the next 16 bit field
*/
- unpacked[i] = *((__be32 *)field);
- field += 2;
- nr_assoc_doms++;
+ last = new;
+ is_32bit = true;
}
}
diff --git a/arch/powerpc/mm/vphn.h b/arch/powerpc/mm/vphn.h
index 96af9a4..fe8b780 100644
--- a/arch/powerpc/mm/vphn.h
+++ b/arch/powerpc/mm/vphn.h
@@ -6,10 +6,10 @@
#define VPHN_REGISTER_COUNT 6
/*
- * 6 64-bit registers unpacked into 12 32-bit associativity values. To form
- * the complete property we have to add the length in the first cell.
+ * 6 64-bit registers unpacked into up to 24 be32 associativity values. To
+ * form the complete property we have to add the length in the first cell.
*/
-#define VPHN_ASSOC_BUFSIZE (VPHN_REGISTER_COUNT*sizeof(u64)/sizeof(u32) + 1)
+#define VPHN_ASSOC_BUFSIZE (VPHN_REGISTER_COUNT*sizeof(u64)/sizeof(u16) + 1)
extern int vphn_unpack_associativity(const long *packed, __be32 *unpacked);
^ permalink raw reply related
* [PATCH v2 1/4] powerpc/vphn: clarify the H_HOME_NODE_ASSOCIATIVITY API
From: Greg Kurz @ 2014-12-17 9:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20141217094007.16957.70423.stgit@bahia.local>
The number of values returned by the H_HOME_NODE_ASSOCIATIVITY h_call deserves
to be explicitly defined, for a better understanding of the code.
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
No changes in v2.
arch/powerpc/mm/numa.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 417b0a5..2a83e48 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1247,11 +1247,15 @@ static int update_cpu_associativity_changes_mask(void)
return cpumask_weight(changes);
}
+/* The H_HOME_NODE_ASSOCIATIVITY h_call returns 6 64-bit registers.
+ */
+#define VPHN_REGISTER_COUNT 6
+
/*
* 6 64-bit registers unpacked into 12 32-bit associativity values. To form
* the complete property we have to add the length in the first cell.
*/
-#define VPHN_ASSOC_BUFSIZE (6*sizeof(u64)/sizeof(u32) + 1)
+#define VPHN_ASSOC_BUFSIZE (VPHN_REGISTER_COUNT*sizeof(u64)/sizeof(u32) + 1)
/*
* Convert the associativity domain numbers returned from the hypervisor
@@ -1309,7 +1313,7 @@ static long hcall_vphn(unsigned long cpu, __be32 *associativity)
int i;
rc = plpar_hcall9(H_HOME_NODE_ASSOCIATIVITY, retbuf, flags, hwcpu);
- for (i = 0; i < 6; i++)
+ for (i = 0; i < VPHN_REGISTER_COUNT; i++)
retbuf[i] = cpu_to_be64(retbuf[i]);
vphn_unpack_associativity(retbuf, associativity);
^ permalink raw reply related
* [PATCH v2 0/4] VPHN parsing fixes
From: Greg Kurz @ 2014-12-17 9:40 UTC (permalink / raw)
To: linuxppc-dev
Hi,
This series addresses remarks from Ben and Michael (see individual patches).
The most notable changes are:
- the parsing code being pull out into a separate file in patch 3/4. This
allows to write userland tests like the one below.
- a full rewrite of the parsing logic in patch 4/4
--
#include <stdio.h>
#include <byteswap.h>
typedef unsigned long u64;
typedef unsigned int u32;
typedef unsigned short u16;
typedef enum { false = 0, true } bool;
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
#define cpu_to_be32(x) bswap_32(x)
#define be32_to_cpu(x) bswap_32(x)
#define be16_to_cpup(x) bswap_16(*x)
#define cpu_to_be64(x) bswap_64(x)
#else
#define cpu_to_be32(x) (x)
#define be32_to_cpu(x) (x)
#define be16_to_cpup(x) (*x)
#define cpu_to_be64(x) (x)
#endif
#define pr_debug(...) printf(__VA_ARGS__)
#include "vphn.c"
void print_packed(const long *packed)
{
char *p = (char*) packed;
int i;
printf("\nRegisters:\n");
for (i = 0; i < VPHN_REGISTER_COUNT; i++)
printf("0x%016lx\n", packed[i]);
printf("\nMemory layout:\n");
for (i = 0; i < 6; i++) {
printf("0x %02hhx %02hhx %02hhx %02hhx"
" %02hhx %02hhx %02hhx %02hhx\n",
*(p + 0), *(p + 1), *(p + 2), *(p + 3),
*(p + 4), *(p + 5), *(p + 6), *(p + 7));
p += 8;
}
putchar('\n');
}
void print_unpacked(const __be32 *unpacked)
{
int i;
printf("\nVPHN associativity:\n");
for (i = 0; i <= be32_to_cpu(unpacked[0]); i++)
printf("0x%08x\n", be32_to_cpu(unpacked[i]));
putchar('\n');
}
int main(int argc, char **argv)
{
int i;
struct {
const char *descr;
long packed[VPHN_REGISTER_COUNT];
} data[] = {
{
"16-bit and 32-bit",
0x8001800280038004,
0x8005800680078008,
0x000000090000000a,
0x0000000b0000000c,
0xffffffffffffffff,
0xffffffffffffffff
},
{
"filled with 16-bit",
0x8001800280038004,
0x8005800680078008,
0x8009800a800b800c,
0x800d800e800f8010,
0x8011801280138014,
0x8015801680178018,
},
{
"filled with 32-bit",
0x0000000100000002,
0x0000000300000004,
0x0000000500000006,
0x0000000700000008,
0x000000090000000a,
0x0000000b0000000c,
},
{
"32-bit has all ones in 16 lower bits",
0x0001ffff80028003,
0xffffffffffffffff,
0xffffffffffffffff,
0xffffffffffffffff,
0xffffffffffffffff,
0xffffffffffffffff,
},
{
"32-bit accross two 64-bit registers",
0x8001000000020000,
0x0003000000048005,
0xffffffffffffffff,
0xffffffffffffffff,
0xffffffffffffffff,
0xffffffffffffffff,
},
{
"Truncated last 32-bit",
0x0000000100000002,
0x0000000300000004,
0x0000000500000006,
0x0000000700000008,
0x000000090000000a,
0x0000000b800c0bad,
},
};
for (i = 0; i < sizeof(data) / sizeof(data[0]); i++) {
__be32 unpacked[VPHN_ASSOC_BUFSIZE] = { 0 };
printf("\n==================================================\n");
printf("\nSet #%d: %s\n", i, data[i].descr);
printf("\n==================================================\n");
print_packed(data[i].packed);
vphn_unpack_associativity(data[i].packed, unpacked);
print_unpacked(unpacked);
}
return 0;
}
---
Greg Kurz (4):
powerpc/vphn: clarify the H_HOME_NODE_ASSOCIATIVITY API
powerpc/vphn: move endianness fixing to vphn_unpack_associativity()
powerpc/vphn: move VPHN parsing logic to a separate file
powerpc/vphn: parsing code rewrite
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/numa.c | 55 ++----------------------------------
arch/powerpc/mm/vphn.c | 70 ++++++++++++++++++++++++++++++++++++++++++++++
arch/powerpc/mm/vphn.h | 16 +++++++++++
4 files changed, 90 insertions(+), 52 deletions(-)
create mode 100644 arch/powerpc/mm/vphn.c
create mode 100644 arch/powerpc/mm/vphn.h
--
Greg
^ permalink raw reply
* [PATCH v2 3/4] powerpc/vphn: move VPHN parsing logic to a separate file
From: Greg Kurz @ 2014-12-17 9:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20141217094007.16957.70423.stgit@bahia.local>
The goal behind this patch is to be able to write userland tests for the
VPHN parsing code.
Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
---
arch/powerpc/mm/Makefile | 1 +
arch/powerpc/mm/numa.c | 61 ++--------------------------------------------
arch/powerpc/mm/vphn.c | 50 ++++++++++++++++++++++++++++++++++++++
arch/powerpc/mm/vphn.h | 16 ++++++++++++
4 files changed, 70 insertions(+), 58 deletions(-)
create mode 100644 arch/powerpc/mm/vphn.c
create mode 100644 arch/powerpc/mm/vphn.h
diff --git a/arch/powerpc/mm/Makefile b/arch/powerpc/mm/Makefile
index 438dcd3..9c8770b 100644
--- a/arch/powerpc/mm/Makefile
+++ b/arch/powerpc/mm/Makefile
@@ -24,6 +24,7 @@ obj-$(CONFIG_40x) += 40x_mmu.o
obj-$(CONFIG_44x) += 44x_mmu.o
obj-$(CONFIG_PPC_FSL_BOOK3E) += fsl_booke_mmu.o
obj-$(CONFIG_NEED_MULTIPLE_NODES) += numa.o
+obj-$(CONFIG_PPC_SPLPAR) += vphn.o
obj-$(CONFIG_PPC_MM_SLICES) += slice.o
obj-y += hugetlbpage.o
ifeq ($(CONFIG_HUGETLB_PAGE),y)
diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
index 2e36a6f..008af17 100644
--- a/arch/powerpc/mm/numa.c
+++ b/arch/powerpc/mm/numa.c
@@ -1177,6 +1177,9 @@ u64 memory_hotplug_max(void)
/* Virtual Processor Home Node (VPHN) support */
#ifdef CONFIG_PPC_SPLPAR
+
+#include "vphn.h"
+
struct topology_update_data {
struct topology_update_data *next;
unsigned int cpu;
@@ -1247,64 +1250,6 @@ static int update_cpu_associativity_changes_mask(void)
return cpumask_weight(changes);
}
-/* The H_HOME_NODE_ASSOCIATIVITY h_call returns 6 64-bit registers.
- */
-#define VPHN_REGISTER_COUNT 6
-
-/*
- * 6 64-bit registers unpacked into 12 32-bit associativity values. To form
- * the complete property we have to add the length in the first cell.
- */
-#define VPHN_ASSOC_BUFSIZE (VPHN_REGISTER_COUNT*sizeof(u64)/sizeof(u32) + 1)
-
-/*
- * Convert the associativity domain numbers returned from the hypervisor
- * to the sequence they would appear in the ibm,associativity property.
- */
-static int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
-{
- __be64 be_packed[VPHN_REGISTER_COUNT];
- int i, nr_assoc_doms = 0;
- const __be16 *field = (const __be16 *) be_packed;
-
-#define VPHN_FIELD_UNUSED (0xffff)
-#define VPHN_FIELD_MSB (0x8000)
-#define VPHN_FIELD_MASK (~VPHN_FIELD_MSB)
-
- /* Let's recreate the original stream. */
- for (i = 0; i < VPHN_REGISTER_COUNT; i++)
- be_packed[i] = cpu_to_be64(packed[i]);
-
- for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
- if (be16_to_cpup(field) == VPHN_FIELD_UNUSED) {
- /* All significant fields processed, and remaining
- * fields contain the reserved value of all 1's.
- * Just store them.
- */
- unpacked[i] = *((__be32 *)field);
- field += 2;
- } else if (be16_to_cpup(field) & VPHN_FIELD_MSB) {
- /* Data is in the lower 15 bits of this field */
- unpacked[i] = cpu_to_be32(
- be16_to_cpup(field) & VPHN_FIELD_MASK);
- field++;
- nr_assoc_doms++;
- } else {
- /* Data is in the lower 15 bits of this field
- * concatenated with the next 16 bit field
- */
- unpacked[i] = *((__be32 *)field);
- field += 2;
- nr_assoc_doms++;
- }
- }
-
- /* The first cell contains the length of the property */
- unpacked[0] = cpu_to_be32(nr_assoc_doms);
-
- return nr_assoc_doms;
-}
-
/*
* Retrieve the new associativity information for a virtual processor's
* home node.
diff --git a/arch/powerpc/mm/vphn.c b/arch/powerpc/mm/vphn.c
new file mode 100644
index 0000000..c49ed51
--- /dev/null
+++ b/arch/powerpc/mm/vphn.c
@@ -0,0 +1,50 @@
+#include <asm/byteorder.h>
+#include "vphn.h"
+
+/*
+ * Convert the associativity domain numbers returned from the hypervisor
+ * to the sequence they would appear in the ibm,associativity property.
+ */
+int vphn_unpack_associativity(const long *packed, __be32 *unpacked)
+{
+ __be64 be_packed[VPHN_REGISTER_COUNT];
+ int i, nr_assoc_doms = 0;
+ const __be16 *field = (const __be16 *) be_packed;
+
+#define VPHN_FIELD_UNUSED (0xffff)
+#define VPHN_FIELD_MSB (0x8000)
+#define VPHN_FIELD_MASK (~VPHN_FIELD_MSB)
+
+ /* Let's recreate the original stream. */
+ for (i = 0; i < VPHN_REGISTER_COUNT; i++)
+ be_packed[i] = cpu_to_be64(packed[i]);
+
+ for (i = 1; i < VPHN_ASSOC_BUFSIZE; i++) {
+ if (be16_to_cpup(field) == VPHN_FIELD_UNUSED) {
+ /* All significant fields processed, and remaining
+ * fields contain the reserved value of all 1's.
+ * Just store them.
+ */
+ unpacked[i] = *((__be32 *)field);
+ field += 2;
+ } else if (be16_to_cpup(field) & VPHN_FIELD_MSB) {
+ /* Data is in the lower 15 bits of this field */
+ unpacked[i] = cpu_to_be32(
+ be16_to_cpup(field) & VPHN_FIELD_MASK);
+ field++;
+ nr_assoc_doms++;
+ } else {
+ /* Data is in the lower 15 bits of this field
+ * concatenated with the next 16 bit field
+ */
+ unpacked[i] = *((__be32 *)field);
+ field += 2;
+ nr_assoc_doms++;
+ }
+ }
+
+ /* The first cell contains the length of the property */
+ unpacked[0] = cpu_to_be32(nr_assoc_doms);
+
+ return nr_assoc_doms;
+}
diff --git a/arch/powerpc/mm/vphn.h b/arch/powerpc/mm/vphn.h
new file mode 100644
index 0000000..96af9a4
--- /dev/null
+++ b/arch/powerpc/mm/vphn.h
@@ -0,0 +1,16 @@
+#ifndef _ARCH_POWERPC_MM_VPHN_H_
+#define _ARCH_POWERPC_MM_VPHN_H_
+
+/* The H_HOME_NODE_ASSOCIATIVITY h_call returns 6 64-bit registers.
+ */
+#define VPHN_REGISTER_COUNT 6
+
+/*
+ * 6 64-bit registers unpacked into 12 32-bit associativity values. To form
+ * the complete property we have to add the length in the first cell.
+ */
+#define VPHN_ASSOC_BUFSIZE (VPHN_REGISTER_COUNT*sizeof(u64)/sizeof(u32) + 1)
+
+extern int vphn_unpack_associativity(const long *packed, __be32 *unpacked);
+
+#endif
^ permalink raw reply related
* RE: PROBLEM: USB isochronous urb leak on EHCI driver
From: Michael Tessier @ 2014-12-17 14:06 UTC (permalink / raw)
To: Peter Chen; +Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <BN3PR0301MB0849131A4DE4D5E0E425C769816D0@BN3PR0301MB0849.namprd03.prod.outlook.com>
>>=20
>> My configuration:
>> -----------------
>>=20
>> Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller)=20
>> Linux
>> kernel: 2.6.31, using EHCI USB driver
>> Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b)
>> Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901)
>>=20
>> Note: each codec is being used in R/W access, so with 4 codecs, I have
>> 4 playback and 4 capture streams.
>>=20
>> My problem:
>> -----------
>>=20
>> I have usb urb leaks when connecting more than 1 codec to the USB 1.1 Hu=
b.
>> (the result is that some of the audio data is not transferred, part of=20
>> the sound is simply missing) No problem when using only 1 of the 4=20
>> codecs connected to the hub; When I connect a second codec, the sound=20
>> quality starts to degrade. With
>> 3 codecs, we just cannot recognize a speach.
>>=20
>> Tests and observations:
>> -----------------------
>>=20
>> Since I have 3 usb ports available on the i.MX512, I tried to connect
>> 3 codecs directly on USB ports: the sound is perfect on each of the thre=
e ports.
>>=20
>> I bought a consumer USB 2.0 Hub: no problem when using 3 codecs=20
>> connected to that Hub, however, the audio will completly stop on all=20
>> channels when connecting the 4th codec.
>>=20
>> I checked the communication between the Hub (USB 1.1) and the Host=20
>> controller (USB 2.0) with a scope and concluded that the communication=20
>> speed is 1.5 MBytes/s has expected (so the communication is downgraded=20
>> to USB 1.1, since codecs and hub are USB
>> 1.1 devices).
>>=20
>> Also, I know that there is physically enough bandwidth to transfer the=20
>> data for two reasons:
>> 1) I have an older CPU with a USB 1.1 host controller (using the OHCI=20
>> driver), using the same hub and the same codecs: works like a champ,=20
>> using less than 50% of the available bandwidth (observed with a
>> scope)
>> 2) 1 audio stream is 32khz-mono, 16 bits =3D 64 kB/s,
>> 4 codecs =3D 8 streams(R/W) x 64 kB/s =3D 512 kB/s (out of 1.5MB/s)
>>=20
>> I noticed that my sound problem starts happening with only 2 codecs
>> (4 streams, 256 kB/s). I first thought that it was a bandwidth=20
>> limitation, so I decided to connect only 1 codec using more bandwidth.
>> I configured it to 48khz-stereo (16-bits), using 384 kB/s for both=20
>> read and write
>> streams: no problem. With that configuration, the scope shows about=20
>> 30% of total bandwidth usage (300us used out of 1ms periods). Then, I=20
>> added a second codec (48khz-stereo-16bits): very strange, now the=20
>> total bandwidth usage felt down to about 200us, which seems to keep=20
>> the same, whatever the number of codec I add (I also tried 3 and=20
>> 4...). So it looks like the scheduler is not able to properly allocate=20
>> Isochronous time slots when more than one device is connected to the
>> hub. However, without the hub, it works perfectly.
>>=20
>
> I am wonder if it is similar problem I met when using multiple interrupt =
transfers, when you find you lose the data, try to run 'top' to show cpu ut=
ilization, if > it is close to 100%, it means the ehci can't queue request =
in time, so the host can't send IN token in time.
>
> Using a USB bus analyzer can also verify it.
>
> Peter
Thanks Peter, I did it, the CPU usage varies between 0% and 4% so this is n=
ot the case here.
^ permalink raw reply
* Re: [PATCH] powerpc: powernv: Return to cpu offline loop when finished in KVM guest
From: Alexander Graf @ 2014-12-17 12:40 UTC (permalink / raw)
To: Paul Mackerras, linuxppc-dev; +Cc: kvm, kvm-ppc
In-Reply-To: <20141203034840.GA612@iris.ozlabs.ibm.com>
On 03.12.14 04:48, Paul Mackerras wrote:
> When a secondary hardware thread has finished running a KVM guest, we
> currently put that thread into nap mode using a nap instruction in
> the KVM code. This changes the code so that instead of doing a nap
> instruction directly, we instead cause the call to power7_nap() that
> put the thread into nap mode to return. The reason for doing this is
> to avoid having the KVM code having to know what low-power mode to
> put the thread into.
>
> In the case of a secondary thread used to run a KVM guest, the thread
> will be offline from the point of view of the host kernel, and the
> relevant power7_nap() call is the one in pnv_smp_cpu_disable().
> In this case we don't want to clear pending IPIs in the offline loop
> in that function, since that might cause us to miss the wakeup for
> the next time the thread needs to run a guest. To tell whether or
> not to clear the interrupt, we use the SRR1 value returned from
> power7_nap(), and check if it indicates an external interrupt. We
> arrange that the return from power7_nap() when we have finished running
> a guest returns 0, so pending interrupts don't get flushed in that
> case.
>
> Note that it is important a secondary thread that has finished
> executing in the guest, or that didn't have a guest to run, should
> not return to power7_nap's caller while the kvm_hstate.hwthread_req
> flag in the PACA is non-zero, because the return from power7_nap
> will reenable the MMU, and the MMU might still be in guest context.
> In this situation we spin at low priority in real mode waiting for
> hwthread_req to become zero.
>
> Signed-off-by: Paul Mackerras <paulus@samba.org>
> ---
> I think this would be best going through the powerpc tree. Alex,
> if you can give me an acked-by for this that would be appreciated.
Acked-by: Alexander Graf <agraf@suse.de>
Alex
^ permalink raw reply
* Re: [PATCH] arch: powerpc: kvm: book3s_paired_singles.c: Remove unused function
From: Alexander Graf @ 2014-12-17 12:13 UTC (permalink / raw)
To: Rickard Strandqvist, Gleb Natapov
Cc: kvm, linux-kernel, kvm-ppc, Paul Mackerras, Paolo Bonzini,
linuxppc-dev
In-Reply-To: <1417991354-19932-1-git-send-email-rickard_strandqvist@spectrumdigital.se>
On 07.12.14 23:29, Rickard Strandqvist wrote:
> Remove the function inst_set_field() that is not used anywhere.
>
> This was partially found by using a static code analysis program called cppcheck.
>
> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@spectrumdigital.se>
Thanks, applied all unused function patches in KVM PPC code to
kvm-ppc-queue.
Alex
^ permalink raw reply
* [PATCH] powerpc: lib: Do not include string.o in obj-y twice
From: Andreas Ruprecht @ 2014-12-17 11:05 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Andreas Ruprecht, Paul Mackerras, linuxppc-dev, linux-kernel
In the Makefile, string.o (which is generated from string.S) is
included into the list of objects being built unconditionally
(obj-y) in line 12.
Additionally, if CONFIG_PPC64 is set, it is included again in
line 17.
This patch removes the latter unnecessary inclusion.
Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
---
arch/powerpc/lib/Makefile | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/powerpc/lib/Makefile b/arch/powerpc/lib/Makefile
index 597562f69b2d..1b01159b81f3 100644
--- a/arch/powerpc/lib/Makefile
+++ b/arch/powerpc/lib/Makefile
@@ -14,8 +14,7 @@ obj-y := string.o alloc.o \
obj-$(CONFIG_PPC32) += div64.o copy_32.o
obj-$(CONFIG_PPC64) += copypage_64.o copyuser_64.o \
- usercopy_64.o mem_64.o string.o \
- hweight_64.o \
+ usercopy_64.o mem_64.o hweight_64.o \
copyuser_power7.o string_64.o copypage_power7.o
ifeq ($(CONFIG_GENERIC_CSUM),)
obj-y += checksum_$(CONFIG_WORD_SIZE).o
--
1.9.1
^ permalink raw reply related
* Re: [PATCH 13/18] powerpc/uaccess: fix sparse errors
From: Benjamin Herrenschmidt @ 2014-12-17 11:05 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linux-arch, Paul Mackerras, linuxppc-dev, linux-kernel,
Michael S. Tsirkin
In-Reply-To: <3268591.VzqP3kr6UD@wuerfel>
On Wed, 2014-12-17 at 11:53 +0100, Arnd Bergmann wrote:
> On Wednesday 17 December 2014 11:52:36 Benjamin Herrenschmidt wrote:
> > On Tue, 2014-12-16 at 18:47 +0200, Michael S. Tsirkin wrote:
> > > On Sun, Dec 14, 2014 at 06:52:51PM +0200, Michael S. Tsirkin wrote:
> > > > virtio wants to read bitwise types from userspace using get_user. At the
> > > > moment this triggers sparse errors, since the value is passed through an
> > > > integer.
> > > >
> > > > Fix that up using __force.
> > > >
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > >
> > > Ping.
> > > Do powerpc maintainers consider fixing sparse errors
> > > applicable for 3.19?
> > > If yes, can you pls merge this patch?
> >
> > Relax Our patches are tracked in Patchwork and such fixes aren't
> > necessarily constrained by the merge window. Michael will probably
> > pick it up but don't expect systematic replies to patches in 2 days ...
> >
> > Also, when sending a series like that where one of us only gets
> > CCed on one of the patch, it helps to make it clear whether you
> > only expect an ack or whether you expect us to take the patch.
>
> Michael initially asked how these patches should merged, and as I
> discussed with him on IRC, I wouldn't take them through the asm-generic
> tree for 3.19 at this point, but I offered to take the ones that
> are not picked up by arch maintainers through that tree for 3.20.
>
> I also recommend to him to clarify this with maintainers of the
> architectures he cares about most so they can decide whether to pick
> it up or not, which triggered the message above.
Ok, I incorrectly assumed the above was a nag for not looking at his
patch yet :)
I don't have any objection, but I'm leaving the merging for now to
Michael (and possibly for ever, we'll see ... :) as I'm on vacation
until end of January.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 13/18] powerpc/uaccess: fix sparse errors
From: Arnd Bergmann @ 2014-12-17 10:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linux-arch, Paul Mackerras, linux-kernel, Michael S. Tsirkin
In-Reply-To: <1418777556.27103.7.camel@kernel.crashing.org>
On Wednesday 17 December 2014 11:52:36 Benjamin Herrenschmidt wrote:
> On Tue, 2014-12-16 at 18:47 +0200, Michael S. Tsirkin wrote:
> > On Sun, Dec 14, 2014 at 06:52:51PM +0200, Michael S. Tsirkin wrote:
> > > virtio wants to read bitwise types from userspace using get_user. At the
> > > moment this triggers sparse errors, since the value is passed through an
> > > integer.
> > >
> > > Fix that up using __force.
> > >
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> >
> > Ping.
> > Do powerpc maintainers consider fixing sparse errors
> > applicable for 3.19?
> > If yes, can you pls merge this patch?
>
> Relax Our patches are tracked in Patchwork and such fixes aren't
> necessarily constrained by the merge window. Michael will probably
> pick it up but don't expect systematic replies to patches in 2 days ...
>
> Also, when sending a series like that where one of us only gets
> CCed on one of the patch, it helps to make it clear whether you
> only expect an ack or whether you expect us to take the patch.
Michael initially asked how these patches should merged, and as I
discussed with him on IRC, I wouldn't take them through the asm-generic
tree for 3.19 at this point, but I offered to take the ones that
are not picked up by arch maintainers through that tree for 3.20.
I also recommend to him to clarify this with maintainers of the
architectures he cares about most so they can decide whether to pick
it up or not, which triggered the message above.
Arnd
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Don't use local named register variable in current_thread_info
From: Alexander Graf @ 2014-12-17 9:27 UTC (permalink / raw)
To: Anton Blanchard; +Cc: ulrich.weigand, paulus, Scott Wood, linuxppc-dev
In-Reply-To: <20141217144459.09701a76@kryten>
On 17.12.14 04:44, Anton Blanchard wrote:
> Hi Alex,
>
>> Git bisect managed to point me to this commit as the offender for
>> OOPSes on e5500 and e6500 (and maybe the G4 as well, not sure).
>>
>> Doing a git revert of this commit on top of linus/master makes things
>> work fine for me again.
>
> Ouch, sorry for that, I'll work to reproduce. What gcc version are you
> using?
I'm running
gcc (SUSE Linux) 4.7.2 20130108 [gcc-4_7-branch revision 195012]
which is basically the one from openSUSE 12.3 for ppc64.
I've also uploaded 2 builds, one with the patch applied (broken) and one
without (works):
http://csgraf.de/agraf/current_thread_info/vmlinux.broken.xz
http://csgraf.de/agraf/current_thread_info/vmlinux.works.xz
Interestingly enough I did not see this on IBM POWER systems, but maybe
that's because most of them compile their own kernels with local,
different compilers in my test runs and the only one that does base on
the same compiler doesn't run on nfsroot.
My iBook G4 target is affected by this as well and reverting this patch
also makes it work again. Maybe we're just running over some stack?
Alex
^ permalink raw reply
* [v2 PATCH 1/2] powerpc32: adds handling of _PAGE_RO
From: Christophe Leroy @ 2014-12-17 9:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
scottwood
Cc: linuxppc-dev, linux-kernel
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only) bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of _PAGE_RW
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2 is a complete rework compared to v1
arch/powerpc/include/asm/pgtable-ppc32.h | 11 ++++++-----
arch/powerpc/include/asm/pgtable.h | 10 +++++++---
arch/powerpc/include/asm/pte-common.h | 27 ++++++++++++++++++---------
arch/powerpc/mm/gup.c | 2 ++
arch/powerpc/mm/mem.c | 2 +-
arch/powerpc/mm/pgtable_32.c | 24 ++++++++++++++++++++----
6 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/arch/powerpc/include/asm/pgtable-ppc32.h b/arch/powerpc/include/asm/pgtable-ppc32.h
index 543bb8e..64ed9e1 100644
--- a/arch/powerpc/include/asm/pgtable-ppc32.h
+++ b/arch/powerpc/include/asm/pgtable-ppc32.h
@@ -125,7 +125,7 @@ extern int icache_44x_need_flush;
#ifndef __ASSEMBLY__
#define pte_clear(mm, addr, ptep) \
- do { pte_update(ptep, ~_PAGE_HASHPTE, 0); } while (0)
+ do { pte_update(ptep, ~_PAGE_HASHPTE, _PAGE_RO); } while (0)
#define pmd_none(pmd) (!pmd_val(pmd))
#define pmd_bad(pmd) (pmd_val(pmd) & _PMD_BAD)
@@ -268,14 +268,14 @@ static inline int __ptep_test_and_clear_young(unsigned int context, unsigned lon
static inline pte_t ptep_get_and_clear(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- return __pte(pte_update(ptep, ~_PAGE_HASHPTE, 0));
+ return __pte(pte_update(ptep, ~_PAGE_HASHPTE, _PAGE_RO));
}
#define __HAVE_ARCH_PTEP_SET_WRPROTECT
static inline void ptep_set_wrprotect(struct mm_struct *mm, unsigned long addr,
pte_t *ptep)
{
- pte_update(ptep, (_PAGE_RW | _PAGE_HWWRITE), 0);
+ pte_update(ptep, (_PAGE_RW | _PAGE_HWWRITE), _PAGE_RO);
}
static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
unsigned long addr, pte_t *ptep)
@@ -287,8 +287,9 @@ static inline void huge_ptep_set_wrprotect(struct mm_struct *mm,
static inline void __ptep_set_access_flags(pte_t *ptep, pte_t entry)
{
unsigned long bits = pte_val(entry) &
- (_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_EXEC);
- pte_update(ptep, 0, bits);
+ (_PAGE_DIRTY | _PAGE_ACCESSED | _PAGE_RW | _PAGE_RO |
+ _PAGE_EXEC);
+ pte_update(ptep, _PAGE_RO, bits);
}
#define __HAVE_ARCH_PTE_SAME
diff --git a/arch/powerpc/include/asm/pgtable.h b/arch/powerpc/include/asm/pgtable.h
index 316f9a5..88f65fd 100644
--- a/arch/powerpc/include/asm/pgtable.h
+++ b/arch/powerpc/include/asm/pgtable.h
@@ -30,12 +30,14 @@ struct mm_struct;
#include <asm/tlbflush.h>
/* Generic accessors to PTE bits */
-static inline int pte_write(pte_t pte) { return pte_val(pte) & _PAGE_RW; }
+static inline int pte_write(pte_t pte)
+{ return (pte_val(pte) & (_PAGE_RW | _PAGE_RO)) != _PAGE_RO; }
static inline int pte_dirty(pte_t pte) { return pte_val(pte) & _PAGE_DIRTY; }
static inline int pte_young(pte_t pte) { return pte_val(pte) & _PAGE_ACCESSED; }
static inline int pte_file(pte_t pte) { return pte_val(pte) & _PAGE_FILE; }
static inline int pte_special(pte_t pte) { return pte_val(pte) & _PAGE_SPECIAL; }
-static inline int pte_none(pte_t pte) { return (pte_val(pte) & ~_PTE_NONE_MASK) == 0; }
+static inline int pte_none(pte_t pte)
+{ return (pte_val(pte) & ~_PTE_NONE_MASK) == _PAGE_RO; }
static inline pgprot_t pte_pgprot(pte_t pte) { return __pgprot(pte_val(pte) & PAGE_PROT_BITS); }
#ifdef CONFIG_NUMA_BALANCING
@@ -115,12 +117,14 @@ static inline unsigned long pte_pfn(pte_t pte) {
/* Generic modifiers for PTE bits */
static inline pte_t pte_wrprotect(pte_t pte) {
- pte_val(pte) &= ~(_PAGE_RW | _PAGE_HWWRITE); return pte; }
+ pte_val(pte) &= ~(_PAGE_RW | _PAGE_HWWRITE);
+ pte_val(pte) |= _PAGE_RO; return pte; }
static inline pte_t pte_mkclean(pte_t pte) {
pte_val(pte) &= ~(_PAGE_DIRTY | _PAGE_HWWRITE); return pte; }
static inline pte_t pte_mkold(pte_t pte) {
pte_val(pte) &= ~_PAGE_ACCESSED; return pte; }
static inline pte_t pte_mkwrite(pte_t pte) {
+ pte_val(pte) &= ~_PAGE_RO;
pte_val(pte) |= _PAGE_RW; return pte; }
static inline pte_t pte_mkdirty(pte_t pte) {
pte_val(pte) |= _PAGE_DIRTY; return pte; }
diff --git a/arch/powerpc/include/asm/pte-common.h b/arch/powerpc/include/asm/pte-common.h
index e040c35..7ed79b8 100644
--- a/arch/powerpc/include/asm/pte-common.h
+++ b/arch/powerpc/include/asm/pte-common.h
@@ -34,6 +34,12 @@
#ifndef _PAGE_PSIZE
#define _PAGE_PSIZE 0
#endif
+/* _PAGE_RO and _PAGE_RW shall not be defined at the same time */
+#ifndef _PAGE_RO
+#define _PAGE_RO 0
+#else
+#define _PAGE_RW 0
+#endif
#ifndef _PMD_PRESENT_MASK
#define _PMD_PRESENT_MASK _PMD_PRESENT
#endif
@@ -42,10 +48,10 @@
#define PMD_PAGE_SIZE(pmd) bad_call_to_PMD_PAGE_SIZE()
#endif
#ifndef _PAGE_KERNEL_RO
-#define _PAGE_KERNEL_RO 0
+#define _PAGE_KERNEL_RO (_PAGE_RO)
#endif
#ifndef _PAGE_KERNEL_ROX
-#define _PAGE_KERNEL_ROX (_PAGE_EXEC)
+#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_RO)
#endif
#ifndef _PAGE_KERNEL_RW
#define _PAGE_KERNEL_RW (_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE)
@@ -95,7 +101,7 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
/* Mask of bits returned by pte_pgprot() */
#define PAGE_PROT_BITS (_PAGE_GUARDED | _PAGE_COHERENT | _PAGE_NO_CACHE | \
_PAGE_WRITETHRU | _PAGE_ENDIAN | _PAGE_4K_PFN | \
- _PAGE_USER | _PAGE_ACCESSED | \
+ _PAGE_USER | _PAGE_ACCESSED | _PAGE_RO | \
_PAGE_RW | _PAGE_HWWRITE | _PAGE_DIRTY | _PAGE_EXEC)
#ifdef CONFIG_NUMA_BALANCING
@@ -126,13 +132,16 @@ extern unsigned long bad_call_to_PMD_PAGE_SIZE(void);
*
* Note due to the way vm flags are laid out, the bits are XWR
*/
-#define PAGE_NONE __pgprot(_PAGE_BASE)
+#define PAGE_NONE __pgprot(_PAGE_BASE | _PAGE_RO)
#define PAGE_SHARED __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW)
-#define PAGE_SHARED_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW | _PAGE_EXEC)
-#define PAGE_COPY __pgprot(_PAGE_BASE | _PAGE_USER)
-#define PAGE_COPY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_EXEC)
-#define PAGE_READONLY __pgprot(_PAGE_BASE | _PAGE_USER)
-#define PAGE_READONLY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_EXEC)
+#define PAGE_SHARED_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RW | \
+ _PAGE_EXEC)
+#define PAGE_COPY __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RO)
+#define PAGE_COPY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RO | \
+ _PAGE_EXEC)
+#define PAGE_READONLY __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RO)
+#define PAGE_READONLY_X __pgprot(_PAGE_BASE | _PAGE_USER | _PAGE_RO | \
+ _PAGE_EXEC)
#define __P000 PAGE_NONE
#define __P001 PAGE_READONLY
diff --git a/arch/powerpc/mm/gup.c b/arch/powerpc/mm/gup.c
index d874668..fa287fc 100644
--- a/arch/powerpc/mm/gup.c
+++ b/arch/powerpc/mm/gup.c
@@ -30,6 +30,8 @@ static noinline int gup_pte_range(pmd_t pmd, unsigned long addr,
result = _PAGE_PRESENT|_PAGE_USER;
if (write)
result |= _PAGE_RW;
+ else
+ result |= _PAGE_RO;
mask = result | _PAGE_SPECIAL;
ptep = pte_offset_kernel(&pmd, addr);
diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
index 8ebaac7..3a74ee6 100644
--- a/arch/powerpc/mm/mem.c
+++ b/arch/powerpc/mm/mem.c
@@ -329,7 +329,7 @@ void __init paging_init(void)
unsigned long end = __fix_to_virt(FIX_HOLE);
for (; v < end; v += PAGE_SIZE)
- map_page(v, 0, 0); /* XXX gross */
+ map_page(v, 0, _PAGE_RO); /* XXX gross */
#endif
#ifdef CONFIG_HIGHMEM
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
index a349089..e1e30bb 100644
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -96,6 +96,18 @@ void pgd_free(struct mm_struct *mm, pgd_t *pgd)
#endif
}
+static inline void pte_alloc_clear(pte_t *pte)
+{
+#if _PAGE_RO == 0
+ clear_page(pte);
+#else
+ int i;
+
+ for (i = 0; i < PTRS_PER_PTE; i++)
+ pte[i] = __pte(_PAGE_RO);
+#endif
+}
+
__init_refok pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long address)
{
pte_t *pte;
@@ -103,11 +115,12 @@ __init_refok pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long add
extern void *early_get_page(void);
if (mem_init_done) {
- pte = (pte_t *)__get_free_page(GFP_KERNEL|__GFP_REPEAT|__GFP_ZERO);
+ pte = (pte_t *)__get_free_page(GFP_KERNEL|__GFP_REPEAT);
+ pte_alloc_clear(pte);
} else {
pte = (pte_t *)early_get_page();
if (pte)
- clear_page(pte);
+ pte_alloc_clear(pte);
}
return pte;
}
@@ -115,12 +128,15 @@ __init_refok pte_t *pte_alloc_one_kernel(struct mm_struct *mm, unsigned long add
pgtable_t pte_alloc_one(struct mm_struct *mm, unsigned long address)
{
struct page *ptepage;
+ pte_t *pte;
- gfp_t flags = GFP_KERNEL | __GFP_REPEAT | __GFP_ZERO;
+ gfp_t flags = GFP_KERNEL | __GFP_REPEAT;
ptepage = alloc_pages(flags, 0);
if (!ptepage)
return NULL;
+ pte = (pte_t *)pfn_to_kaddr(page_to_pfn(ptepage));
+ pte_alloc_clear(pte);
if (!pgtable_page_ctor(ptepage)) {
__free_page(ptepage);
return NULL;
@@ -148,7 +164,7 @@ void __iomem *
ioremap_prot(phys_addr_t addr, unsigned long size, unsigned long flags)
{
/* writeable implies dirty for kernel addresses */
- if (flags & _PAGE_RW)
+ if ((flags & (_PAGE_RW | _PAGE_RO)) != _PAGE_RO)
flags |= _PAGE_DIRTY | _PAGE_HWWRITE;
/* we don't want to let _PAGE_USER and _PAGE_EXEC leak out */
--
2.1.0
^ permalink raw reply related
* [v2 PATCH 2/2] powerpc/8xx: use _PAGE_RO instead of _PAGE_RW
From: Christophe Leroy @ 2014-12-17 9:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
scottwood
Cc: linuxppc-dev, linux-kernel
On powerpc 8xx, in TLB entries, 0x400 bit is set to 1 for read-only pages
and is set to 0 for RW pages. So we should use _PAGE_RO instead of _PAGE_RW
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2 is a complete rework compared to v1
arch/powerpc/include/asm/pte-8xx.h | 7 +++----
arch/powerpc/kernel/head_8xx.S | 3 ---
2 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/arch/powerpc/include/asm/pte-8xx.h b/arch/powerpc/include/asm/pte-8xx.h
index daa4616..4f5583e 100644
--- a/arch/powerpc/include/asm/pte-8xx.h
+++ b/arch/powerpc/include/asm/pte-8xx.h
@@ -46,7 +46,7 @@
* require a TLB exception handler change. It is assumed unused bits
* are always zero.
*/
-#define _PAGE_RW 0x0400 /* lsb PP bits, inverted in HW */
+#define _PAGE_RO 0x0400 /* lsb PP bits */
#define _PAGE_USER 0x0800 /* msb PP bits */
/* set when neither _PAGE_USER nor _PAGE_RW are set */
#define _PAGE_KNLRO 0x0200
@@ -62,9 +62,8 @@
#define PTE_ATOMIC_UPDATES 1
/* We need to add _PAGE_SHARED to kernel pages */
-#define _PAGE_KERNEL_RO (_PAGE_SHARED | _PAGE_KNLRO)
-#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_KNLRO)
-#define _PAGE_KERNEL_RW (_PAGE_DIRTY | _PAGE_RW | _PAGE_HWWRITE)
+#define _PAGE_KERNEL_RO (_PAGE_SHARED | _PAGE_RO | _PAGE_KNLRO)
+#define _PAGE_KERNEL_ROX (_PAGE_EXEC | _PAGE_RO | _PAGE_KNLRO)
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_PTE_8xx_H */
diff --git a/arch/powerpc/kernel/head_8xx.S b/arch/powerpc/kernel/head_8xx.S
index 3d4b8ee..807b0db 100644
--- a/arch/powerpc/kernel/head_8xx.S
+++ b/arch/powerpc/kernel/head_8xx.S
@@ -441,9 +441,6 @@ DataStoreTLBMiss:
and r11, r11, r10
rlwimi r10, r11, 0, _PAGE_PRESENT
#endif
- /* invert RW */
- xori r10, r10, _PAGE_RW
-
/* The Linux PTE won't go exactly into the MMU TLB.
* Software indicator bits 22 and 28 must be clear.
* Software indicator bits 24, 25, 26, and 27 must be
--
2.1.0
^ permalink raw reply related
* [PATCH v2 0/2] powerpc32: handle inverted _PAGE_RW bit outside of TLB handlers
From: Christophe Leroy @ 2014-12-17 9:14 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
scottwood
Cc: linuxppc-dev, linux-kernel
Some powerpc like the 8xx don't have a RW bit in PTE bits but a RO (Read Only) bit.
This patch implements the handling of a _PAGE_RO flag to be used in place of _PAGE_RW
Patchset:
1) powerpc32: adds handling of _PAGE_RO
2) powerpc/8xx: use _PAGE_RO instead of _PAGE_RW
All changes have been successfully tested on MPC885
Signed-off-by: Christophe Leroy <christophe.leroy@c-s.fr>
Tested-by: Christophe Leroy <christophe.leroy@c-s.fr>
---
v2 is a complete rework compared to v1
arch/powerpc/include/asm/pgtable-ppc32.h | 11 ++++++-----
arch/powerpc/include/asm/pgtable.h | 10 +++++++---
arch/powerpc/include/asm/pte-8xx.h | 7 +++----
arch/powerpc/include/asm/pte-common.h | 27 ++++++++++++++++++---------
arch/powerpc/kernel/head_8xx.S | 3 ---
arch/powerpc/mm/gup.c | 2 ++
arch/powerpc/mm/mem.c | 2 +-
arch/powerpc/mm/pgtable_32.c | 24 ++++++++++++++++++++----
8 files changed, 57 insertions(+), 29 deletions(-)
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Don't use local named register variable in current_thread_info
From: Anton Blanchard @ 2014-12-17 3:44 UTC (permalink / raw)
To: Alexander Graf; +Cc: ulrich.weigand, paulus, Scott Wood, linuxppc-dev
In-Reply-To: <5490D981.7040905@suse.de>
Hi Alex,
> Git bisect managed to point me to this commit as the offender for
> OOPSes on e5500 and e6500 (and maybe the G4 as well, not sure).
>
> Doing a git revert of this commit on top of linus/master makes things
> work fine for me again.
Ouch, sorry for that, I'll work to reproduce. What gcc version are you
using?
Anton
^ permalink raw reply
* RE: PROBLEM: USB isochronous urb leak on EHCI driver
From: Peter Chen @ 2014-12-17 2:21 UTC (permalink / raw)
To: Michael Tessier; +Cc: linux-usb@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <66A26A9AA227D947AF088537F041526E1FF44F@VSVR-EX10-MB1.pocatec.com>
=20
>=20
> My configuration:
> -----------------
>=20
> Host: Freescale i.MX512 with ARM Cortex A8 (USB 2.0 host controller) Linu=
x
> kernel: 2.6.31, using EHCI USB driver
> Hub: 4-PORT USB 1.1 HUB (Texas Instruments PN: tusb2046b)
> Devices: 4 USB 1.1 audio codecs (Texas Instruments PN: pcm2901)
>=20
> Note: each codec is being used in R/W access, so with 4 codecs, I have
> 4 playback and 4 capture streams.
>=20
> My problem:
> -----------
>=20
> I have usb urb leaks when connecting more than 1 codec to the USB 1.1 Hub=
.
> (the result is that some of the audio data is not transferred, part of th=
e sound is
> simply missing) No problem when using only 1 of the 4 codecs connected to=
the
> hub; When I connect a second codec, the sound quality starts to degrade. =
With
> 3 codecs, we just cannot recognize a speach.
>=20
> Tests and observations:
> -----------------------
>=20
> Since I have 3 usb ports available on the i.MX512, I tried to connect
> 3 codecs directly on USB ports: the sound is perfect on each of the three=
ports.
>=20
> I bought a consumer USB 2.0 Hub: no problem when using 3 codecs connected
> to that Hub, however, the audio will completly stop on all channels when
> connecting the 4th codec.
>=20
> I checked the communication between the Hub (USB 1.1) and the Host
> controller (USB 2.0) with a scope and concluded that the communication sp=
eed
> is 1.5 MBytes/s has expected (so the communication is downgraded to USB 1=
.1,
> since codecs and hub are USB
> 1.1 devices).
>=20
> Also, I know that there is physically enough bandwidth to transfer the da=
ta for
> two reasons:
> 1) I have an older CPU with a USB 1.1 host controller (using the OHCI dri=
ver),
> using the same hub and the same codecs: works like a champ, using less th=
an
> 50% of the available bandwidth (observed with a
> scope)
> 2) 1 audio stream is 32khz-mono, 16 bits =3D 64 kB/s,
> 4 codecs =3D 8 streams(R/W) x 64 kB/s =3D 512 kB/s (out of 1.5MB/s)
>=20
> I noticed that my sound problem starts happening with only 2 codecs
> (4 streams, 256 kB/s). I first thought that it was a bandwidth limitation=
, so I
> decided to connect only 1 codec using more bandwidth.
> I configured it to 48khz-stereo (16-bits), using 384 kB/s for both read a=
nd write
> streams: no problem. With that configuration, the scope shows about 30% o=
f
> total bandwidth usage (300us used out of 1ms periods). Then, I added a se=
cond
> codec (48khz-stereo-16bits): very strange, now the total bandwidth usage =
felt
> down to about 200us, which seems to keep the same, whatever the number of
> codec I add (I also tried 3 and 4...). So it looks like the scheduler is =
not able to
> properly allocate Isochronous time slots when more than one device is
> connected to the hub. However, without the hub, it works perfectly.
>=20
I am wonder if it is similar problem I met when using multiple interrupt tr=
ansfers,
when you find you lose the data, try to run 'top' to show cpu utilization, =
if it is
close to 100%, it means the ehci can't queue request in time, so the host c=
an't send IN
token in time.
Using a USB bus analyzer can also verify it.
Peter
> Another interresting fact is that at application level, the Read and Writ=
e
> operations are returning the good amount of bytes read/written.
> This is not the case at kernel level: I noticed that function "usb_submit=
_urb"
> (from /drivers/usb/core/urb.c) will only tranfer part of the "urbs" when =
the
> sound is degraded. I tried to figure out where the leak comes from withou=
t
> success. Also, there are no error messages from kernel so everything appe=
ars
> to work well, excepted that part of the sound is missing!
>=20
> I can't change my hardware (this is in the hand of customers), so the onl=
y
> possible solution for me is to correct the software.
>=20
> I tried to change my ehci driver with the one from kernel 2.6.39.4 but di=
d not
> work, same problem.
>=20
> Question:
> ---------
>=20
> Before attempting to upgrade to an earlier kernel driver (this is a fairl=
y big
> amount of work), I would really like to know if this problem would still =
be in the
> 3.x kernels. Has anyone seen that issue in 3.x kernels?
>=20
> I am pretty new to USB driver debugging, so any ideas of where/how to fin=
d
> solutions will be appreciated. Thank you very much in advance for the sup=
port.
> Also don't hesitate to redirect me if I'm not at the right place to ask t=
hese
> questions. I can also provide some code if someone need it to help.
>=20
> Attached is a dump of my "dmesg" after startup.
>=20
> Michael Tessier
>=20
>=20
>=20
>=20
>=20
>=20
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: Don't use local named register variable in current_thread_info
From: Alexander Graf @ 2014-12-17 1:16 UTC (permalink / raw)
To: Anton Blanchard, benh, paulus, mpe, ulrich.weigand
Cc: Scott Wood, linuxppc-dev
In-Reply-To: <1414727247-31838-1-git-send-email-anton__19440.5086375356$1414727300$gmane$org@samba.org>
On 31.10.14 04:47, Anton Blanchard wrote:
> LLVM doesn't support local named register variables and is unlikely
> to. current_thread_info is using one, fix it by moving it out and
> calling it __current_r1().
>
> I gave it a bit of an obscure name because we don't want anyone else
> using it - they should use current_stack_pointer(). This specific
> case is performance critical and we can't afford to call a function
> to get it. Furthermore it isn't important to know exactly where in
> the stack we are since we mask the lower bits.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Git bisect managed to point me to this commit as the offender for OOPSes
on e5500 and e6500 (and maybe the G4 as well, not sure).
Doing a git revert of this commit on top of linus/master makes things
work fine for me again.
Alex
Oops: Kernel access of bad area, sig: 11 [#2]
SMP NR_CPUS=16 CoreNet Generic
Modules linked in:
CPU: 1 PID: 339 Comm: kworker/1:1 Tainted: G D
3.18.0-09423-g988adfd #1
Workqueue: rpciod .rpc_async_schedule
task: c0000001f6397500 ti: c0000001f6638000 task.ti: c0000001f6638000
NIP: c0000000004817a4 LR: c0000000004817a4 CTR: 0000000000000000
REGS: c0000001f663b0e0 TRAP: 0300 Tainted: G D
(3.18.0-09423-g988adfd)
MSR: 0000000080029000 <CE,EE,ME> CR: 24ad2e42 XER: 00000000
DEAR: 202031303438355f ESR: 0000000000000000 SOFTE: 1
GPR00: c0000000004817a4 c0000001f663b360 c000000000988028 000000007f24333d
GPR04: 5ff5738c1f2ebfb1 0000000000000000 0000000000000000 00000000000008f8
GPR08: c000000000480ae8 2020313034383537 36204b4220617320 6469726563740a31
GPR12: 3937302d30312d30 c00000000fff8780 c00000000007f988 c0000001f64c1600
GPR16: 0000000000000000 0000000000000000 0000000000000000 00000000000005dc
GPR20: c0000000009b8028 c00000007e034200 0000000000000548 c000000000000000
GPR24: c0000001f663b4b0 00000000b225831e 0000000000000000 0000000000000080
GPR28: 0000000000000548 00000000000008f8 0000000000000548 0000000000000094
NIP [c0000000004817a4] .__skb_checksum+0x194/0x378
LR [c0000000004817a4] .__skb_checksum+0x194/0x378
Call Trace:
[c0000001f663b360] [c0000000004817a4] .__skb_checksum+0x194/0x378
(unreliable)
[c0000001f663b440] [c0000000004819b4] .skb_checksum+0x2c/0x3c
[c0000001f663b4c0] [c0000000004fd0a8] .udp4_hwcsum+0xa8/0x16c
[c0000001f663b560] [c0000000004fd440] .udp_send_skb+0x2d4/0x370
[c0000001f663b600] [c0000000004fd51c] .udp_push_pending_frames+0x40/0x94
[c0000001f663b680] [c0000000004fec08] .udp_sendpage+0x150/0x1b4
[c0000001f663b770] [c00000000050ae54] .inet_sendpage+0xa0/0x120
[c0000001f663b810] [c00000000059c8cc] .xs_sendpages+0x2d0/0x30c
[c0000001f663b8d0] [c00000000059cae4] .xs_udp_send_request+0x58/0x120
[c0000001f663b970] [c000000000598f04] .xprt_transmit+0x80/0x36c
[c0000001f663ba20] [c0000000005942d8] .call_transmit+0x19c/0x254
[c0000001f663bab0] [c00000000059ff64] .__rpc_execute+0xbc/0x3c0
[c0000001f663bb90] [c0000000000797f8] .process_one_work+0x1c0/0x474
[c0000001f663bc40] [c00000000007a518] .worker_thread+0x17c/0x54c
[c0000001f663bd30] [c00000000007fa8c] .kthread+0x104/0x124
[c0000001f663be30] [c000000000000884] .ret_from_kernel_thread+0x58/0xd4
Instruction dump:
7d1f3a14 7c6a1850 e9580000 7fbd4050 786334e4 e90a0000 7c63ba14 f8490028
7c63ea14 7d0903a6 e84a0008 4e800421 <e8490028> 7c641b78 78270464 e9580008
---[ end trace 51b7414695b0cafe ]---
note: kworker/1:1[339] exited with preempt_count 1
Unable to handle kernel paging request for data at address
0xffffffffffffffd8
^ 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