Re: [PATCH V2 1/2] powerpc, perf: Ignore separate BHRB privilege state filter request
On 06/06/2013 10:26 AM, Michael Neuling wrote: Anshuman Khandual khand...@linux.vnet.ibm.com wrote: Completely ignore BHRB privilege state filter request as we are already configuring that with privilege state filtering attribute for the accompanying PMU event. This would help achieve cleaner user space interaction for BHRB. This patch fixes a situation like this Before patch:- ./perf record -j any -e branch-misses:k ls Error: The sys_perf_event_open() syscall returned with 95 (Operation not supported) for event (branch-misses:k). /bin/dmesg may provide additional information. No CONFIG_PERF_EVENTS=y kernel support configured? Here 'perf record' actually copies over ':k' filter request into BHRB privilege state filter config and our previous check in kernel would fail that. After patch:- - ./perf record -j any -e branch-misses:k ls perf perf.data perf.data.old test-mmap-ring [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.002 MB perf.data (~102 samples) ] Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com --- arch/powerpc/perf/power8-pmu.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c index f7d1c4f..3a58416 100644 --- a/arch/powerpc/perf/power8-pmu.c +++ b/arch/powerpc/perf/power8-pmu.c @@ -525,16 +525,12 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type) u64 pmu_bhrb_filter = 0; u64 br_privilege = branch_sample_type ONLY_PLM; -/* BHRB and regular PMU events share the same prvillege state +/* BHRB and regular PMU events share the same privilege state * filter configuration. BHRB is always recorded along with a - * regular PMU event. So privilege state filter criteria for BHRB - * and the companion PMU events has to be the same. As a default - * perf record tool sets all privillege bits ON when no filter - * criteria is provided in the command line. So as along as all - * privillege bits are ON or they are OFF, we are good to go. + * regular PMU event. As the privilege state filter is handled + * in the basic PMC configuration of the accompanying regular + * PMU event, we ignore any separate BHRB specific request. */ -if ((br_privilege != 7) (br_privilege != 0)) -return -1; br_privilege is now unused which causes this compile error. arch/powerpc/perf/power8-pmu.c:526:6: error: unused variable ‘br_privilege’ [-Werror=unused-variable] I assume since you didn't compile test this code, you also didn't runtime test it either?!!?!?!? Always compile with the cross compiler ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make I copied over arch/powerpc/config/pseries_defconfig and compiled it. Some how it missed to be a 64 bit kernel config which resulted in shutting down compilation of arch/powerpc/perf/power8-pmu.c file. So never encountered this compiler warning message before. Will fix this. Regards Anshuman ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V10 00/15] THP support for PPC64
Andrew Morton a...@linux-foundation.org writes: On Thu, 06 Jun 2013 09:31:06 +1000 Benjamin Herrenschmidt b...@kernel.crashing.org wrote: On Wed, 2013-06-05 at 20:58 +0530, Aneesh Kumar K.V wrote: This is the second patchset needed to support THP on ppc64. Some of the changes included in this series are tricky in that it changes the powerpc linux page table walk subtly. We also overload few of the pte flags for ptes at PMD level (huge page PTEs). The related mm/ changes are already merged to Andrew's -mm tree. If I am to put that into powerpc-next, I need the dependent mm/ changes as well. Do you have them in the form of a separate git tree that is *exactly* (same SHA1s) what is expected to go upstream via Andrew ? Andrew, are they fully acked on your side and ready to go ? Not being on linuxppc-dev I'm at a bit of a loss here. I assume we're referring to mm-thp-add-pmd-args-to-pgtable-deposit-and-withdraw-apis.patch mm-thp-withdraw-the-pgtable-after-pmdp-related-operations.patch mm-thp-withdraw-the-pgtable-after-pmdp-related-operations-fix.patch mm-thp-dont-use-hpage_shift-in-transparent-hugepage-code.patch mm-thp-deposit-the-transpare-huge-pgtable-before-set_pmd.patch There is one more: mm/THP: Use the right function when updating access flags mm-thp-use-the-right-function-when-updating-access-flags.patc -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] net: Unbreak compat_sys_{send,recv}msg
I broke them in this commit:
commit 1be374a0518a288147c6a7398792583200a67261
Author: Andy Lutomirski l...@amacapital.net
Date: Wed May 22 14:07:44 2013 -0700
net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept
MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints. It
also reverts some unnecessary checks in sys_socketcall.
Apparently I was suffering from underscore blindness the first time around.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
I've tested this a little, but I'm not sure I have a great test case.
If the decision is that it's better to leave this for the 3.11, I can send
a squashed version. Note that the oops that this fixes is only an oops if
the other patches in the original series are applied.
(FWIW, I wasn't sure how to submit this stuff in the first place. I submitted
some kernel hardening patches for the x86 tree that converted an access_ok
oddity in the net code into an actual oops. In a bit of looking, I couldn't
find any failure mode other than a -EFAULT return without the other patches
applied. This was clear in the patch series description but not in the
change log message for the net part.)
include/linux/socket.h | 3 +++
net/compat.c | 13 +++--
net/socket.c | 72 +++---
3 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 2b9f74b..e897bdc 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -321,6 +321,9 @@ extern int put_cmsg(struct msghdr*, int level, int type,
int len, void *data);
struct timespec;
+/* The __sys_...msg variants allow MSG_CMSG_COMPAT */
+extern long __sys_recvmsg(int fd, struct msghdr __user *msg, unsigned flags);
+extern long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags);
extern int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int
vlen,
unsigned int flags, struct timespec *timeout);
extern int __sys_sendmmsg(int fd, struct mmsghdr __user *mmsg,
diff --git a/net/compat.c b/net/compat.c
index 79ae884..f0a1ba6 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -734,19 +734,25 @@ static unsigned char nas[21] = {
asmlinkage long compat_sys_sendmsg(int fd, struct compat_msghdr __user *msg,
unsigned int flags)
{
- return sys_sendmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
+ if (flags MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_sendmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_sendmmsg(int fd, struct compat_mmsghdr __user *mmsg,
unsigned int vlen, unsigned int flags)
{
+ if (flags MSG_CMSG_COMPAT)
+ return -EINVAL;
return __sys_sendmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_recvmsg(int fd, struct compat_msghdr __user *msg,
unsigned int flags)
{
- return sys_recvmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
+ if (flags MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_recvmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_recv(int fd, void __user *buf, size_t len, unsigned
int flags)
@@ -768,6 +774,9 @@ asmlinkage long compat_sys_recvmmsg(int fd, struct
compat_mmsghdr __user *mmsg,
int datagrams;
struct timespec ktspec;
+ if (flags MSG_CMSG_COMPAT)
+ return -EINVAL;
+
if (COMPAT_USE_64BIT_TIME)
return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT,
diff --git a/net/socket.c b/net/socket.c
index 0e16888..e216502 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1978,7 +1978,7 @@ struct used_address {
unsigned int name_len;
};
-static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
+static int ___sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
struct msghdr *msg_sys, unsigned int flags,
struct used_address *used_address)
{
@@ -2093,26 +2093,30 @@ out:
* BSD sendmsg interface
*/
-SYSCALL_DEFINE3(sendmsg, int, fd, struct msghdr __user *, msg, unsigned int,
flags)
+long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags)
{
int fput_needed, err;
struct msghdr msg_sys;
struct socket *sock;
- if (flags MSG_CMSG_COMPAT)
- return -EINVAL;
-
sock = sockfd_lookup_light(fd, err, fput_needed);
if (!sock)
goto out;
- err = __sys_sendmsg(sock, msg, msg_sys, flags, NULL);
+ err = ___sys_sendmsg(sock, msg, msg_sys, flags, NULL);
Re: [PATCH -V10 00/15] THP support for PPC64
On Thu, 06 Jun 2013 11:35:47 +0530 Aneesh Kumar K.V
aneesh.ku...@linux.vnet.ibm.com wrote:
Andrew Morton a...@linux-foundation.org writes:
On Thu, 06 Jun 2013 09:31:06 +1000 Benjamin Herrenschmidt
b...@kernel.crashing.org wrote:
On Wed, 2013-06-05 at 20:58 +0530, Aneesh Kumar K.V wrote:
This is the second patchset needed to support THP on ppc64. Some of the
changes
included in this series are tricky in that it changes the powerpc linux
page table
walk subtly. We also overload few of the pte flags for ptes at PMD level
(huge
page PTEs).
The related mm/ changes are already merged to Andrew's -mm tree.
If I am to put that into powerpc-next, I need the dependent mm/ changes as
well.
Do you have them in the form of a separate git tree that is *exactly*
(same SHA1s)
what is expected to go upstream via Andrew ?
Andrew, are they fully acked on your side and ready to go ?
Not being on linuxppc-dev I'm at a bit of a loss here.
I assume we're referring to
mm-thp-add-pmd-args-to-pgtable-deposit-and-withdraw-apis.patch
mm-thp-withdraw-the-pgtable-after-pmdp-related-operations.patch
mm-thp-withdraw-the-pgtable-after-pmdp-related-operations-fix.patch
mm-thp-dont-use-hpage_shift-in-transparent-hugepage-code.patch
mm-thp-deposit-the-transpare-huge-pgtable-before-set_pmd.patch
There is one more:
mm/THP: Use the right function when updating access flags
mm-thp-use-the-right-function-when-updating-access-flags.patc
Hereunder. This actually precedes the above four(+fix) patches.
From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Subject: mm/thp: use the correct function when updating access flags
We should use pmdp_set_access_flags to update access flags. Archs like
powerpc use extra checks(_PAGE_BUSY) when updating a hugepage PTE. A
set_pmd_at doesn't do those checks. We should use set_pmd_at only when
updating a none hugepage PTE.
Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com
Cc: Andrea Arcangeli aarca...@redhat.coma
Signed-off-by: Andrew Morton a...@linux-foundation.org
---
mm/huge_memory.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff -puN
mm/huge_memory.c~mm-thp-use-the-right-function-when-updating-access-flags
mm/huge_memory.c
--- a/mm/huge_memory.c~mm-thp-use-the-right-function-when-updating-access-flags
+++ a/mm/huge_memory.c
@@ -1265,7 +1265,9 @@ struct page *follow_trans_huge_pmd(struc
* young bit, instead of the current set_pmd_at.
*/
_pmd = pmd_mkyoung(pmd_mkdirty(*pmd));
- set_pmd_at(mm, addr HPAGE_PMD_MASK, pmd, _pmd);
+ if (pmdp_set_access_flags(vma, addr HPAGE_PMD_MASK,
+ pmd, _pmd, 1))
+ update_mmu_cache_pmd(vma, addr, pmd);
}
if ((flags FOLL_MLOCK) (vma-vm_flags VM_LOCKED)) {
if (page-mapping trylock_page(page)) {
_
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: Unbreak compat_sys_{send,recv}msg
From: Andy Lutomirski l...@amacapital.net
Date: Wed, 5 Jun 2013 22:38:26 -0700
I broke them in this commit:
commit 1be374a0518a288147c6a7398792583200a67261
Author: Andy Lutomirski l...@amacapital.net
Date: Wed May 22 14:07:44 2013 -0700
net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept
MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints. It
also reverts some unnecessary checks in sys_socketcall.
Apparently I was suffering from underscore blindness the first time around.
Signed-off-by: Andy Lutomirski l...@amacapital.net
Eric, can you test this patch too?
Thanks.
---
I've tested this a little, but I'm not sure I have a great test case.
If the decision is that it's better to leave this for the 3.11, I can send
a squashed version. Note that the oops that this fixes is only an oops if
the other patches in the original series are applied.
(FWIW, I wasn't sure how to submit this stuff in the first place. I submitted
some kernel hardening patches for the x86 tree that converted an access_ok
oddity in the net code into an actual oops. In a bit of looking, I couldn't
find any failure mode other than a -EFAULT return without the other patches
applied. This was clear in the patch series description but not in the
change log message for the net part.)
include/linux/socket.h | 3 +++
net/compat.c | 13 +++--
net/socket.c | 72
+++---
3 files changed, 47 insertions(+), 41 deletions(-)
diff --git a/include/linux/socket.h b/include/linux/socket.h
index 2b9f74b..e897bdc 100644
--- a/include/linux/socket.h
+++ b/include/linux/socket.h
@@ -321,6 +321,9 @@ extern int put_cmsg(struct msghdr*, int level, int type,
int len, void *data);
struct timespec;
+/* The __sys_...msg variants allow MSG_CMSG_COMPAT */
+extern long __sys_recvmsg(int fd, struct msghdr __user *msg, unsigned flags);
+extern long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags);
extern int __sys_recvmmsg(int fd, struct mmsghdr __user *mmsg, unsigned int
vlen,
unsigned int flags, struct timespec *timeout);
extern int __sys_sendmmsg(int fd, struct mmsghdr __user *mmsg,
diff --git a/net/compat.c b/net/compat.c
index 79ae884..f0a1ba6 100644
--- a/net/compat.c
+++ b/net/compat.c
@@ -734,19 +734,25 @@ static unsigned char nas[21] = {
asmlinkage long compat_sys_sendmsg(int fd, struct compat_msghdr __user *msg,
unsigned int flags)
{
- return sys_sendmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
+ if (flags MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_sendmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_sendmmsg(int fd, struct compat_mmsghdr __user
*mmsg,
unsigned int vlen, unsigned int flags)
{
+ if (flags MSG_CMSG_COMPAT)
+ return -EINVAL;
return __sys_sendmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_recvmsg(int fd, struct compat_msghdr __user *msg,
unsigned int flags)
{
- return sys_recvmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
+ if (flags MSG_CMSG_COMPAT)
+ return -EINVAL;
+ return __sys_recvmsg(fd, (struct msghdr __user *)msg, flags |
MSG_CMSG_COMPAT);
}
asmlinkage long compat_sys_recv(int fd, void __user *buf, size_t len,
unsigned int flags)
@@ -768,6 +774,9 @@ asmlinkage long compat_sys_recvmmsg(int fd, struct
compat_mmsghdr __user *mmsg,
int datagrams;
struct timespec ktspec;
+ if (flags MSG_CMSG_COMPAT)
+ return -EINVAL;
+
if (COMPAT_USE_64BIT_TIME)
return __sys_recvmmsg(fd, (struct mmsghdr __user *)mmsg, vlen,
flags | MSG_CMSG_COMPAT,
diff --git a/net/socket.c b/net/socket.c
index 0e16888..e216502 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -1978,7 +1978,7 @@ struct used_address {
unsigned int name_len;
};
-static int __sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
+static int ___sys_sendmsg(struct socket *sock, struct msghdr __user *msg,
struct msghdr *msg_sys, unsigned int flags,
struct used_address *used_address)
{
@@ -2093,26 +2093,30 @@ out:
* BSD sendmsg interface
*/
-SYSCALL_DEFINE3(sendmsg, int, fd, struct msghdr __user *, msg, unsigned int,
flags)
+long __sys_sendmsg(int fd, struct msghdr __user *msg, unsigned flags)
{
int fput_needed, err;
struct msghdr msg_sys;
struct socket *sock;
- if (flags MSG_CMSG_COMPAT)
- return -EINVAL;
-
sock =
RE: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
This looks like a bit much for 3.10 (certainly, subject lines like refactor and enhance and add support aren't going to make Linus happy given that we're past rc4) so I think we should apply http://patchwork.ozlabs.org/patch/242896/ for 3.10. Then for 3.11, revert it after applying this patchset. Why not 1/6 plus e6500 removal? 1/6 is not a bugfix. Not sure I get it. Isn't this a better fix for AltiVec build breakage: -#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 42 -#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 43 +#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 32 +#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 33 This removes the need for additional kvm_handlers. Obvious this doesn't make AltiVec to work so we still need to disable e6500. -Mike ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: IBM OpenPower 720 ipr driver woes
On 06/05/2013 04:14 PM, Robert Knight wrote: On 6/3/2013 11:52 PM, Gavin Shan wrote: On Tue, Jun 04, 2013 at 01:16:52PM +1000, Tony Breeds wrote: On Mon, Jun 03, 2013 at 09:40:52PM -0400, Robert Knight wrote: On 6/3/2013 8:01 PM, Tony Breeds wrote: On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote: Device tree struct 0x0482 - 0x0484 Calling quiesce... returning from prom_init [1.376359] ehci-pci :c8:01.2: can't setup Can you try adding debug to the kernel commandline. We're missing a great chunk of detail. If you're starting from scratch either try F18 or the F19 Beta (if you're brave :)) Yours Tony So, two points. Since I have no live disks, I can't copy the dmesg output in dracut onto a disk and just sent it to you -- the only way that I know to get it is cut and paste from a HMC console window into a vi buffer. Okay, when I've been in that situation, I run script locally and then conenct to the HMC console. When you're done you can exit script adn then a file called typescript will exist in the directory you ran script in. It's a less overhead way of doign what you're already doing. [0.087097] NET: Registered protocol family 16 [0.087144] pseries_eeh_init: RTAS service ibm,get-config-addr-info2 and i bm,get-config-addr-info invalid [0.087155] eeh_init: Failed to call platform init function (-22) Hmm this seems pretty strange to me. Gavin are these RTAS tokens supported on older power5 boxes? Yes, Tony. ibm,get-config-addr-info should be supported on Power5 box. Newer PowerBox (e.g. P7) should support ibm,get-config-addr-info2 Please have a try on the attached patch, which is based on mainline (3.10). Thanks, Gavin The system boots with that patch. I applied it to kernel-3.8.11-100. Does that patch resolve all your issues, or are there still issues with ipr remaining after applying the patch? Thanks, Brian -- Brian King Power Linux I/O IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: IBM OpenPower 720 ipr driver woes
On 06/06/2013 07:32 AM, Brian King wrote: On 06/05/2013 04:14 PM, Robert Knight wrote: On 6/3/2013 11:52 PM, Gavin Shan wrote: On Tue, Jun 04, 2013 at 01:16:52PM +1000, Tony Breeds wrote: On Mon, Jun 03, 2013 at 09:40:52PM -0400, Robert Knight wrote: On 6/3/2013 8:01 PM, Tony Breeds wrote: On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote: Device tree struct 0x0482 - 0x0484 Calling quiesce... returning from prom_init [1.376359] ehci-pci :c8:01.2: can't setup Can you try adding debug to the kernel commandline. We're missing a great chunk of detail. If you're starting from scratch either try F18 or the F19 Beta (if you're brave :)) Yours Tony So, two points. Since I have no live disks, I can't copy the dmesg output in dracut onto a disk and just sent it to you -- the only way that I know to get it is cut and paste from a HMC console window into a vi buffer. Okay, when I've been in that situation, I run script locally and then conenct to the HMC console. When you're done you can exit script adn then a file called typescript will exist in the directory you ran script in. It's a less overhead way of doign what you're already doing. [0.087097] NET: Registered protocol family 16 [0.087144] pseries_eeh_init: RTAS service ibm,get-config-addr-info2 and i bm,get-config-addr-info invalid [0.087155] eeh_init: Failed to call platform init function (-22) Hmm this seems pretty strange to me. Gavin are these RTAS tokens supported on older power5 boxes? Yes, Tony. ibm,get-config-addr-info should be supported on Power5 box. Newer PowerBox (e.g. P7) should support ibm,get-config-addr-info2 Please have a try on the attached patch, which is based on mainline (3.10). Thanks, Gavin The system boots with that patch. I applied it to kernel-3.8.11-100. Does that patch resolve all your issues, or are there still issues with ipr remaining after applying the patch? Thanks, Brian Yes. I've started rebuilding the kernel and I'm up to the module building part, so I'd say it is solid. Will this patch make it into some version of the kernel? What was killing me was that it would not complete boot. It now does. I see: [ 11.934481] scsi 0:0:15:0: Resetting device [ 11.934813] ipr 0001:d0:01.0: Adapter being reset as a result of error recovery. on each boot. It does not appear to affect operation. Thank you and the rest of the team for your rapid and helpful responses. Best regards, Robert ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: Unbreak compat_sys_{send,recv}msg
On Thu, 2013-06-06 at 00:26 -0700, David Miller wrote: From: Andy Lutomirski l...@amacapital.net Date: Wed, 5 Jun 2013 22:38:26 -0700 I broke them in this commit: commit 1be374a0518a288147c6a7398792583200a67261 Author: Andy Lutomirski l...@amacapital.net Date: Wed May 22 14:07:44 2013 -0700 net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints. It also reverts some unnecessary checks in sys_socketcall. Apparently I was suffering from underscore blindness the first time around. Signed-off-by: Andy Lutomirski l...@amacapital.net Eric, can you test this patch too? Yes, this fixes the problem as well on x86_64 Tested-by: Eric Dumazet eduma...@google.com Thanks ! PS: I had following fuzz while applying on Linus tree : patching file include/linux/socket.h Hunk #1 succeeded at 320 (offset -1 lines). patching file net/compat.c patching file net/socket.c Hunk #1 succeeded at 1956 (offset -22 lines). Hunk #2 succeeded at 2071 (offset -22 lines). Hunk #3 succeeded at 2125 (offset -22 lines). Hunk #4 succeeded at 2163 (offset -22 lines). Hunk #5 succeeded at 2255 (offset -22 lines). Hunk #6 succeeded at 2317 (offset -22 lines). Hunk #7 succeeded at 2515 (offset -20 lines). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH 2/2] KVM: PPC: Book3E: Get vcpu's last instruction for emulation
lwepx faults needs to be handled by KVM and this implies additional code
in DO_KVM macro to identify the source of the exception originated in
host context. This requires to check the Exception Syndrome Register
(ESR[EPID]) and External PID Load Context Register (EPLC[EGS]) for DTB_MISS,
DSI and LRAT exceptions which is too intrusive for the host.
Get rid of lwepx and acquire last instuction in kvmppc_handle_exit() by
searching for the physical address and kmap it. This fixes an infinite loop
caused by lwepx's data TLB miss handled in the host and the TODO for TLB
eviction and execute-but-not-read entries.
Signed-off-by: Mihai Caraman mihai.cara...@freescale.com
---
arch/powerpc/include/asm/mmu-book3e.h |6 ++-
arch/powerpc/kvm/booke.c |6 +++
arch/powerpc/kvm/booke.h |2 +
arch/powerpc/kvm/bookehv_interrupts.S | 32 ++-
arch/powerpc/kvm/e500.c |4 ++
arch/powerpc/kvm/e500mc.c | 69 +
6 files changed, 91 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/include/asm/mmu-book3e.h
b/arch/powerpc/include/asm/mmu-book3e.h
index 99d43e0..32e470e 100644
--- a/arch/powerpc/include/asm/mmu-book3e.h
+++ b/arch/powerpc/include/asm/mmu-book3e.h
@@ -40,7 +40,10 @@
/* MAS registers bit definitions */
-#define MAS0_TLBSEL(x) (((x) 28) 0x3000)
+#define MAS0_TLBSEL_MASK 0x3000
+#define MAS0_TLBSEL_SHIFT 28
+#define MAS0_TLBSEL(x) (((x) MAS0_TLBSEL_SHIFT) MAS0_TLBSEL_MASK)
+#define MAS0_GET_TLBSEL(mas0) (((mas0) MAS0_TLBSEL_MASK)
MAS0_TLBSEL_SHIFT)
#define MAS0_ESEL_MASK 0x0FFF
#define MAS0_ESEL_SHIFT16
#define MAS0_ESEL(x) (((x) MAS0_ESEL_SHIFT) MAS0_ESEL_MASK)
@@ -58,6 +61,7 @@
#define MAS1_TSIZE_MASK0x0f80
#define MAS1_TSIZE_SHIFT 7
#define MAS1_TSIZE(x) (((x) MAS1_TSIZE_SHIFT) MAS1_TSIZE_MASK)
+#define MAS1_GET_TSIZE(mas1) (((mas1) MAS1_TSIZE_MASK) MAS1_TSIZE_SHIFT)
#define MAS2_EPN (~0xFFFUL)
#define MAS2_X00x0040
diff --git a/arch/powerpc/kvm/booke.c b/arch/powerpc/kvm/booke.c
index 1020119..6764a8e 100644
--- a/arch/powerpc/kvm/booke.c
+++ b/arch/powerpc/kvm/booke.c
@@ -836,6 +836,12 @@ int kvmppc_handle_exit(struct kvm_run *run, struct
kvm_vcpu *vcpu,
/* update before a new last_exit_type is rewritten */
kvmppc_update_timing_stats(vcpu);
+ /*
+* The exception type can change at this point, such as if the TLB entry
+* for the emulated instruction has been evicted.
+*/
+ kvmppc_prepare_for_emulation(vcpu, exit_nr);
+
/* restart interrupts if they were meant for the host */
kvmppc_restart_interrupt(vcpu, exit_nr);
diff --git a/arch/powerpc/kvm/booke.h b/arch/powerpc/kvm/booke.h
index 5fd1ba6..a0d0fea 100644
--- a/arch/powerpc/kvm/booke.h
+++ b/arch/powerpc/kvm/booke.h
@@ -90,6 +90,8 @@ void kvmppc_vcpu_disable_spe(struct kvm_vcpu *vcpu);
void kvmppc_booke_vcpu_load(struct kvm_vcpu *vcpu, int cpu);
void kvmppc_booke_vcpu_put(struct kvm_vcpu *vcpu);
+void kvmppc_prepare_for_emulation(struct kvm_vcpu *vcpu, unsigned int
*exit_nr);
+
enum int_class {
INT_CLASS_NONCRIT,
INT_CLASS_CRIT,
diff --git a/arch/powerpc/kvm/bookehv_interrupts.S
b/arch/powerpc/kvm/bookehv_interrupts.S
index 20c7a54..0538ab9 100644
--- a/arch/powerpc/kvm/bookehv_interrupts.S
+++ b/arch/powerpc/kvm/bookehv_interrupts.S
@@ -120,37 +120,20 @@
.if \flags NEED_EMU
/*
-* This assumes you have external PID support.
-* To support a bookehv CPU without external PID, you'll
-* need to look up the TLB entry and create a temporary mapping.
-*
-* FIXME: we don't currently handle if the lwepx faults. PR-mode
-* booke doesn't handle it either. Since Linux doesn't use
-* broadcast tlbivax anymore, the only way this should happen is
-* if the guest maps its memory execute-but-not-read, or if we
-* somehow take a TLB miss in the middle of this entry code and
-* evict the relevant entry. On e500mc, all kernel lowmem is
-* bolted into TLB1 large page mappings, and we don't use
-* broadcast invalidates, so we should not take a TLB miss here.
-*
-* Later we'll need to deal with faults here. Disallowing guest
-* mappings that are execute-but-not-read could be an option on
-* e500mc, but not on chips with an LRAT if it is used.
+* We don't use external PID support. lwepx faults would need to be
+* handled by KVM and this implies aditional code in DO_KVM (for
+* DTB_MISS, DSI and LRAT) to check ESR[EPID] and EPLC[EGS] which
+* is too intrusive for the host. Get last instuction in
+* kvmppc_handle_exit().
*/
-
- mfspr r3, SPRN_EPLC /* will already have correct ELPID
[PATCH 1/2] KVM: PPC: e500mc: Revert add load inst fixup
lwepx faults needs to be handled by KVM. With the current solution the host kernel searches for the faulting address using its LPID context. If a host translation is found we return to the lwepx instr instead of the fixup ending up in an infinite loop. Revert the commit 1d628af7 add load inst fixup. We will address lwepx issue in a subsequent patch without the need of fixups. Signed-off-by: Mihai Caraman mihai.cara...@freescale.com --- arch/powerpc/kvm/bookehv_interrupts.S | 26 +- 1 files changed, 1 insertions(+), 25 deletions(-) diff --git a/arch/powerpc/kvm/bookehv_interrupts.S b/arch/powerpc/kvm/bookehv_interrupts.S index e8ed7d6..20c7a54 100644 --- a/arch/powerpc/kvm/bookehv_interrupts.S +++ b/arch/powerpc/kvm/bookehv_interrupts.S @@ -29,7 +29,6 @@ #include asm/asm-compat.h #include asm/asm-offsets.h #include asm/bitsperlong.h -#include asm/thread_info.h #ifdef CONFIG_64BIT #include asm/exception-64e.h @@ -162,32 +161,9 @@ PPC_STL r30, VCPU_GPR(R30)(r4) PPC_STL r31, VCPU_GPR(R31)(r4) mtspr SPRN_EPLC, r8 - - /* disable preemption, so we are sure we hit the fixup handler */ - CURRENT_THREAD_INFO(r8, r1) - li r7, 1 - stw r7, TI_PREEMPT(r8) - isync - - /* -* In case the read goes wrong, we catch it and write an invalid value -* in LAST_INST instead. -*/ -1: lwepx r9, 0, r5 -2: -.section .fixup, ax -3: li r9, KVM_INST_FETCH_FAILED - b 2b -.previous -.section __ex_table,a - PPC_LONG_ALIGN - PPC_LONG 1b,3b -.previous - + lwepx r9, 0, r5 mtspr SPRN_EPLC, r3 - li r7, 0 - stw r7, TI_PREEMPT(r8) stw r9, VCPU_LAST_INST(r4) .endif -- 1.7.4.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3, part1 03/10] PCI: Convert alloc_pci_dev(void) to pci_alloc_dev(bus) instead
On Thu 06 Jun 2013 04:07:18 AM CST, Bjorn Helgaas wrote: On Sat, May 25, 2013 at 7:48 AM, Jiang Liu liu...@gmail.com wrote: From: Gu Zheng guz.f...@cn.fujitsu.com Use the new pci_alloc_dev(bus) to replace the existing using of alloc_pci_dev(void). ... diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 26df9c8..d5d18a0 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1130,6 +1130,7 @@ static void pci_release_dev(struct device *dev) struct pci_dev *pci_dev; pci_dev = to_pci_dev(dev); + pci_bus_put(pci_dev-bus); pci_release_capabilities(pci_dev); pci_release_of_node(pci_dev); kfree(pci_dev); I think we should drop the pci_bus reference *last* (before the kfree). Otherwise, we have to audit pci_release_capabilities() and pci_release_of_node() to make sure they don't use pci_dev-bus. I made this change on my branch already; just let me know if you object. Hi Bjorn, You are right, thanks for fixing it. Bjorn ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RFC PATCH 0/6] KVM: PPC: Book3E: AltiVec support
On 06/06/2013 04:42:44 AM, Caraman Mihai Claudiu-B02008 wrote: This looks like a bit much for 3.10 (certainly, subject lines like refactor and enhance and add support aren't going to make Linus happy given that we're past rc4) so I think we should apply http://patchwork.ozlabs.org/patch/242896/ for 3.10. Then for 3.11, revert it after applying this patchset. Why not 1/6 plus e6500 removal? 1/6 is not a bugfix. Not sure I get it. Isn't this a better fix for AltiVec build breakage: -#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 42 -#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 43 +#define BOOKE_INTERRUPT_ALTIVEC_UNAVAIL 32 +#define BOOKE_INTERRUPT_ALTIVEC_ASSIST 33 This removes the need for additional kvm_handlers. Obvious this doesn't make AltiVec to work so we still need to disable e6500. OK, didn't realize you meant it as an alternative fix to what was in my patch. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] net: Unbreak compat_sys_{send,recv}msg
From: Eric Dumazet eric.duma...@gmail.com Date: Thu, 06 Jun 2013 06:45:37 -0700 On Thu, 2013-06-06 at 00:26 -0700, David Miller wrote: From: Andy Lutomirski l...@amacapital.net Date: Wed, 5 Jun 2013 22:38:26 -0700 I broke them in this commit: commit 1be374a0518a288147c6a7398792583200a67261 Author: Andy Lutomirski l...@amacapital.net Date: Wed May 22 14:07:44 2013 -0700 net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg This patch adds __sys_sendmsg and __sys_sendmsg as common helpers that accept MSG_CMSG_COMPAT and blocks MSG_CMSG_COMPAT at the syscall entrypoints. It also reverts some unnecessary checks in sys_socketcall. Apparently I was suffering from underscore blindness the first time around. Signed-off-by: Andy Lutomirski l...@amacapital.net Eric, can you test this patch too? Yes, this fixes the problem as well on x86_64 Tested-by: Eric Dumazet eduma...@google.com Applied, thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V7 09/18] powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format
On 04/28/2013 02:37:30 PM, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com We will be switching PMD_SHIFT to 24 bits to facilitate THP impmenetation. With PMD_SHIFT set to 24, we now have 16MB huge pages allocated at PGD level. That means with 32 bit process we cannot allocate normal pages at all, because we cover the entire address space with one pgd entry. Fix this by switching to a new page table format for hugepages. With the new page table format for 16GB and 16MB hugepages we won't allocate hugepage directory. Instead we encode the PTE information directly at the directory level. This forces 16MB hugepage at PMD level. This will also make the page take walk much simpler later when we add the THP support. With the new table format we have 4 cases for pgds and pmds: (1) invalid (all zeroes) (2) pointer to next table, as normal; bottom 6 bits == 0 (3) leaf pte for huge page, bottom two bits != 00 (4) hugepd pointer, bottom two bits == 00, next 4 bits indicate size of table Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- arch/powerpc/include/asm/page.h| 2 + arch/powerpc/include/asm/pgtable.h | 2 + arch/powerpc/mm/gup.c | 18 +++- arch/powerpc/mm/hugetlbpage.c | 176 +++-- 4 files changed, 168 insertions(+), 30 deletions(-) After this patch, on 64-bit book3e (e5500, and thus 4K pages), I see messages like this after exiting a program that uses hugepages (specifically, qemu): /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221516. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221516. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc2214d6. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc2214d6. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221916. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221916. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc2218d6. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc2218d6. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221496. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221496. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221856. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221856. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221816. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH V2 1/2] powerpc, perf: Ignore separate BHRB privilege state filter request
Anshuman Khandual khand...@linux.vnet.ibm.com wrote: On 06/06/2013 10:26 AM, Michael Neuling wrote: Anshuman Khandual khand...@linux.vnet.ibm.com wrote: Completely ignore BHRB privilege state filter request as we are already configuring that with privilege state filtering attribute for the accompanying PMU event. This would help achieve cleaner user space interaction for BHRB. This patch fixes a situation like this Before patch:- ./perf record -j any -e branch-misses:k ls Error: The sys_perf_event_open() syscall returned with 95 (Operation not supported) for event (branch-misses:k). /bin/dmesg may provide additional information. No CONFIG_PERF_EVENTS=y kernel support configured? Here 'perf record' actually copies over ':k' filter request into BHRB privilege state filter config and our previous check in kernel would fail that. After patch:- - ./perf record -j any -e branch-misses:k ls perf perf.data perf.data.old test-mmap-ring [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.002 MB perf.data (~102 samples) ] Signed-off-by: Anshuman Khandual khand...@linux.vnet.ibm.com --- arch/powerpc/perf/power8-pmu.c | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/perf/power8-pmu.c b/arch/powerpc/perf/power8-pmu.c index f7d1c4f..3a58416 100644 --- a/arch/powerpc/perf/power8-pmu.c +++ b/arch/powerpc/perf/power8-pmu.c @@ -525,16 +525,12 @@ static u64 power8_bhrb_filter_map(u64 branch_sample_type) u64 pmu_bhrb_filter = 0; u64 br_privilege = branch_sample_type ONLY_PLM; - /* BHRB and regular PMU events share the same prvillege state + /* BHRB and regular PMU events share the same privilege state * filter configuration. BHRB is always recorded along with a - * regular PMU event. So privilege state filter criteria for BHRB - * and the companion PMU events has to be the same. As a default - * perf record tool sets all privillege bits ON when no filter - * criteria is provided in the command line. So as along as all - * privillege bits are ON or they are OFF, we are good to go. + * regular PMU event. As the privilege state filter is handled + * in the basic PMC configuration of the accompanying regular + * PMU event, we ignore any separate BHRB specific request. */ - if ((br_privilege != 7) (br_privilege != 0)) - return -1; br_privilege is now unused which causes this compile error. arch/powerpc/perf/power8-pmu.c:526:6: error: unused variable ‘br_privilege’ [-Werror=unused-variable] I assume since you didn't compile test this code, you also didn't runtime test it either?!!?!?!? Always compile with the cross compiler ARCH=powerpc CROSS_COMPILE=powerpc64-linux-gnu- make I copied over arch/powerpc/config/pseries_defconfig and compiled it. Some how it missed to be a 64 bit kernel config which resulted in shutting down compilation of arch/powerpc/perf/power8-pmu.c file. So never encountered this compiler warning message before. Will fix this. I don't understand this at all... pseries_defconfig is a 64bit kernel. BTW. you don't need to copy it. Just do make pseries_defconfig make vmlinux. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: IBM OpenPower 720 ipr driver woes
On Thu, Jun 06, 2013 at 08:39:45AM -0400, Robert Knight wrote: On 06/06/2013 07:32 AM, Brian King wrote: On 06/05/2013 04:14 PM, Robert Knight wrote: On 6/3/2013 11:52 PM, Gavin Shan wrote: On Tue, Jun 04, 2013 at 01:16:52PM +1000, Tony Breeds wrote: On Mon, Jun 03, 2013 at 09:40:52PM -0400, Robert Knight wrote: On 6/3/2013 8:01 PM, Tony Breeds wrote: On Mon, Jun 03, 2013 at 05:20:12PM -0400, Robert Knight wrote: .../... Yes. I've started rebuilding the kernel and I'm up to the module building part, so I'd say it is solid. Will this patch make it into some version of the kernel? The patch is being pushed to mainline or linux-next, and backported to stable-kernel (v3.4+) What was killing me was that it would not complete boot. It now does. I see: [ 11.934481] scsi 0:0:15:0: Resetting device [ 11.934813] ipr 0001:d0:01.0: Adapter being reset as a result of error recovery. on each boot. It does not appear to affect operation. Thank you and the rest of the team for your rapid and helpful responses. Thanks, Gavin ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc/mpc85xx: remove the unneeded pci init functions for corenet ds board
On Mon, Jun 03, 2013 at 11:42:03AM -0500, Scott Wood wrote: On 06/01/2013 07:07:20 PM, Kevin Hao wrote: On Sat, Jun 01, 2013 at 09:47:16PM +1000, Benjamin Herrenschmidt wrote: On Sat, 2013-06-01 at 18:59 +0800, Kevin Hao wrote: The effect of this change is that the isa_io_base will be 0 and the IO resource are equal to the virtual address of the IO space. But the IO functions such as outx/inx should work as well. This is why I ask the above question. What do you think about this? Are there any subtle bugs that will be triggered by this? I don't see any obvious reason why that wouldn't work but like anything in that area, it needs a bit of testing hammering to be sure ;-) Agreed. Please include QEMU in your testing, as that was where breakage was observed that caused us to add the default primary. I tested this on a qemu with the following command: ./qemu-system-ppc -m 1024 -nographic -M ppce500 -kernel ./uImage \ -initrd /root/initrd.gz \ -append root=/dev/ram rw console=ttyS0,115200 ramdisk_size=0x6 \ -cpu e500mc -machine dt_compatible=fsl,,P4080DS Before applying my patch: PCI: Probing PCI hardware fsl-pci e0008000.pci: PCI host bridge to bus :00 pci_bus :00: root bus resource [io 0x-0x] pci_bus :00: root bus resource [mem 0xc000-0xdfff] pci_bus :00: root bus resource [bus 00-ff] pci_bus :00: busn_res: [bus 00-ff] end is updated to ff pci :00:00.0: [1957:0030] type 01 class 0x060400 pci :00:00.0: reg 10: [mem 0xfff0-0x] pci :00:01.0: [1af4:1000] type 00 class 0x02 pci :00:01.0: reg 10: [io 0x-0x001f] pci :00:01.0: reg 14: [mem 0x-0x0fff] pci :00:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring pci :00:00.0: PCI bridge to [bus 01-ff] pci :00:00.0: bridge window [io 0x-0x0fff] pci :00:00.0: bridge window [mem 0x-0x000f] pci :00:00.0: bridge window [mem 0x-0x000f pref] pci_bus :01: busn_res: [bus 01-ff] end is updated to 01 pci_bus :00: busn_res: [bus 00-ff] end is updated to 01 PCI: Cannot allocate resource region 0 of device :00:00.0, will remap PCI :00 Cannot reserve Legacy IO [io 0x-0x0fff] pci :00:00.0: BAR 0: assigned [mem 0xc000-0xc00f] pci :00:00.0: BAR 8: assigned [mem 0xc010-0xc01f] pci :00:01.0: BAR 1: assigned [mem 0xc020-0xc0200fff] pci :00:01.0: BAR 0: assigned [io 0x1000-0x101f] pci :00:00.0: PCI bridge to [bus 01] pci :00:00.0: bridge window [io 0x-0x0fff] pci :00:00.0: bridge window [mem 0xc010-0xc01f] pci_bus :00: resource 4 [io 0x-0x] pci_bus :00: resource 5 [mem 0xc000-0xdfff] pci_bus :01: resource 0 [io 0x-0x0fff] pci_bus :01: resource 1 [mem 0xc010-0xc01f] # lspci -vvv 00:00.0 PCI bridge: Freescale Semiconductor Inc MPC8533E (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 0 Region 0: Memory at c000 (32-bit, non-prefetchable) [size=1M] Bus: primary=00, secondary=00, subordinate=00, sec-latency=0 I/O behind bridge: -0fff Memory behind bridge: -000f Prefetchable memory behind bridge: -000f Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- Reset- FastB2B- PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn- 00:01.0 Ethernet controller: Red Hat, Inc Virtio network device Subsystem: Red Hat, Inc Device 0001 Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast TAbort- TAbort- MAbort- SERR- PERR- INTx- Interrupt: pin A routed to IRQ 17 Region 0: I/O ports at 1000 [disabled] [size=32] Region 1: Memory at c020 (32-bit, non-prefetchable) [disabled] [size=4K] Capabilities: [40] MSI-X: Enable- Count=3 Masked- Vector table: BAR=1 offset= PBA: BAR=1 offset=0800 After applying my patch: PCI: Probing PCI hardware fsl-pci e0008000.pci: PCI host bridge to bus :00 pci_bus :00: root bus resource [io 0xf102-0xf102] (bus address [0x-0x]) pci_bus :00: root bus resource [mem 0xc000-0xdfff] pci_bus :00: root bus resource [bus 00-ff] pci_bus :00: busn_res: [bus 00-ff] end is updated to ff pci :00:00.0: [1957:0030]
Re: SATA FSL and upstreaming
On Thu, 2013-05-16 at 09:56 -0500, Timur Tabi wrote: On Thu, May 16, 2013 at 1:52 AM, Benjamin Herrenschmidt b...@kernel.crashing.org wrote: 3) run pix altbak command 4) check you are on bank4 It stays on bank 0 pix altbank So I got the rev2 chip today, put it in, and PCI-E is still not getting a link. Since the LEDs of the e1000 aren't coming up at all, I *suspect* the slots are getting no power. Is there a power control somewhere ? Maybe some DIP or jumpers that might have gone off ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH -V7 09/18] powerpc: Switch 16GB and 16MB explicit hugepages to a different page table format
Scott Wood scottw...@freescale.com writes: On 04/28/2013 02:37:30 PM, Aneesh Kumar K.V wrote: From: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com We will be switching PMD_SHIFT to 24 bits to facilitate THP impmenetation. With PMD_SHIFT set to 24, we now have 16MB huge pages allocated at PGD level. That means with 32 bit process we cannot allocate normal pages at all, because we cover the entire address space with one pgd entry. Fix this by switching to a new page table format for hugepages. With the new page table format for 16GB and 16MB hugepages we won't allocate hugepage directory. Instead we encode the PTE information directly at the directory level. This forces 16MB hugepage at PMD level. This will also make the page take walk much simpler later when we add the THP support. With the new table format we have 4 cases for pgds and pmds: (1) invalid (all zeroes) (2) pointer to next table, as normal; bottom 6 bits == 0 (3) leaf pte for huge page, bottom two bits != 00 (4) hugepd pointer, bottom two bits == 00, next 4 bits indicate size of table Signed-off-by: Aneesh Kumar K.V aneesh.ku...@linux.vnet.ibm.com --- arch/powerpc/include/asm/page.h| 2 + arch/powerpc/include/asm/pgtable.h | 2 + arch/powerpc/mm/gup.c | 18 +++- arch/powerpc/mm/hugetlbpage.c | 176 +++-- 4 files changed, 168 insertions(+), 30 deletions(-) After this patch, on 64-bit book3e (e5500, and thus 4K pages), I see messages like this after exiting a program that uses hugepages (specifically, qemu): /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221516. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221516. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc2214d6. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc2214d6. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221916. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221916. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc2218d6. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc2218d6. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221496. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221496. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221856. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221856. /home/scott/fsl/git/linux/upstream/mm/memory.c:407: bad pmd 4001fc221816. hmm that implies some of the code paths are not properly #ifdef. The goal was to limit the new format CONFIG_PPC_BOOK3S_64 as seen in the definition of huge_pte_alloc. Can you send me the .config ? -aneesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SATA FSL and upstreaming
On Fri, 2013-06-07 at 13:52 +1000, Benjamin Herrenschmidt wrote: So I got the rev2 chip today, put it in, and PCI-E is still not getting a link. Since the LEDs of the e1000 aren't coming up at all, I *suspect* the slots are getting no power. Is there a power control somewhere ? Maybe some DIP or jumpers that might have gone off ? Forget it, reset all the jumpers to the default setup (found the doc !) and they come up now in slot 4 and 7. It also looks like uBoot now has an e1000 driver so I don't have to use fman (for which I believe there is still no upstream driver right ?) BTW. Is that normal during boot ? Net: Initializing Fman Fman1: Uploading microcode version 106.1.7 PHY reset timed out PHY reset timed out PHY reset timed out PHY reset timed out Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: SATA FSL and upstreaming
-Original Message- From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie- fei.zang=freescale@lists.ozlabs.org] On Behalf Of Benjamin Herrenschmidt Sent: Friday, June 07, 2013 12:40 PM To: Timur Tabi Cc: Xie Shaohui-B21989; Liu Qiang-B32616; Zang Roy-R61911; tiejun.chen; Fleming Andy-AFLEMING; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: SATA FSL and upstreaming On Fri, 2013-06-07 at 13:52 +1000, Benjamin Herrenschmidt wrote: So I got the rev2 chip today, put it in, and PCI-E is still not getting a link. Since the LEDs of the e1000 aren't coming up at all, I *suspect* the slots are getting no power. Is there a power control somewhere ? Maybe some DIP or jumpers that might have gone off ? Forget it, reset all the jumpers to the default setup (found the doc !) and they come up now in slot 4 and 7. It also looks like uBoot now has an e1000 driver so I don't have to use fman (for which I believe there is still no upstream driver right ?) fman in u-boot has been up streamed. It should work. BTW. Is that normal during boot ? Net: Initializing Fman Fman1: Uploading microcode version 106.1.7 PHY reset timed out PHY reset timed out PHY reset timed out PHY reset timed out You can ignore the timeout. Do you plug other card (for example SGMII card) on the board? u-boot detects some card in the slot and tries to init the PHY but fails. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: SATA FSL and upstreaming
On Fri, 2013-06-07 at 04:45 +, Zang Roy-R61911 wrote: Forget it, reset all the jumpers to the default setup (found the doc !) and they come up now in slot 4 and 7. It also looks like uBoot now has an e1000 driver so I don't have to use fman (for which I believe there is still no upstream driver right ?) fman in u-boot has been up streamed. It should work. I don't care much about u-boot :-) It's the kernel that matters to me. BTW. Is that normal during boot ? Net: Initializing Fman Fman1: Uploading microcode version 106.1.7 PHY reset timed out PHY reset timed out PHY reset timed out PHY reset timed out You can ignore the timeout. Do you plug other card (for example SGMII card) on the board? No, only PCIe in slot 4 and 7. u-boot detects some card in the slot and tries to init the PHY but fails. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: SATA FSL and upstreaming
-Original Message- From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] Sent: Friday, June 07, 2013 12:47 PM To: Zang Roy-R61911 Cc: Timur Tabi; Xie Shaohui-B21989; Liu Qiang-B32616; tiejun.chen; Fleming Andy-AFLEMING; Bhushan Bharat-R65777; linuxppc- d...@lists.ozlabs.org Subject: Re: SATA FSL and upstreaming On Fri, 2013-06-07 at 04:45 +, Zang Roy-R61911 wrote: Forget it, reset all the jumpers to the default setup (found the doc !) and they come up now in slot 4 and 7. It also looks like uBoot now has an e1000 driver so I don't have to use fman (for which I believe there is still no upstream driver right ?) fman in u-boot has been up streamed. It should work. I don't care much about u-boot :-) It's the kernel that matters to me. You should matter a working Ethernet port :-) in u-boot. BTW. Is that normal during boot ? Net: Initializing Fman Fman1: Uploading microcode version 106.1.7 PHY reset timed out PHY reset timed out PHY reset timed out PHY reset timed out You can ignore the timeout. Do you plug other card (for example SGMII card) on the board? No, only PCIe in slot 4 and 7. Go ahead ... Unless there is a complete u-boot log, I can comment more. but I do not think it is the focus now ... thanks. Roy ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 17/18] cpufreq: powerpc: move cpufreq driver to drivers/cpufreq
On 31 May 2013 16:20, Viresh Kumar viresh.ku...@linaro.org wrote: On 20 May 2013 10:10, Viresh Kumar viresh.ku...@linaro.org wrote: On 13 May 2013 11:34, Viresh Kumar viresh.ku...@linaro.org wrote: On 22 April 2013 12:19, Viresh Kumar viresh.ku...@linaro.org wrote: On 9 April 2013 14:05, Viresh Kumar viresh.ku...@linaro.org wrote: On 5 April 2013 12:16, Viresh Kumar viresh.ku...@linaro.org wrote: On 4 April 2013 18:24, Viresh Kumar viresh.ku...@linaro.org wrote: This patch moves cpufreq driver of powerpc platform to drivers/cpufreq. Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: Paul Mackerras pau...@samba.org Cc: Olof Johansson o...@lixom.net Cc: linuxppc-dev@lists.ozlabs.org Signed-off-by: Viresh Kumar viresh.ku...@linaro.org --- Compile Tested only. arch/powerpc/platforms/Kconfig | 31 -- arch/powerpc/platforms/pasemi/Makefile | 1 - arch/powerpc/platforms/powermac/Makefile | 2 -- drivers/cpufreq/Kconfig.powerpc| 26 ++ drivers/cpufreq/Makefile | 3 +++ .../cpufreq.c = drivers/cpufreq/pasemi-cpufreq.c | 0 .../cpufreq/pmac32-cpufreq.c | 0 .../cpufreq/pmac64-cpufreq.c | 0 8 files changed, 29 insertions(+), 34 deletions(-) rename arch/powerpc/platforms/pasemi/cpufreq.c = drivers/cpufreq/pasemi-cpufreq.c (100%) rename arch/powerpc/platforms/powermac/cpufreq_32.c = drivers/cpufreq/pmac32-cpufreq.c (100%) rename arch/powerpc/platforms/powermac/cpufreq_64.c = drivers/cpufreq/pmac64-cpufreq.c (100%) Hi Deepthi, Can you help testing this please? Ping!! Ping!! Hi Benjamin, Hope you are back from your vacations. Can you give it a try now? Ping!! Ping!! Hi Rafael, Its been more than 2 months now that this patch was first posted. And the response from Maintainers isn't so great, irrespective of how many times I pinged them. This is what I think: - It looked functionally correct to Benjamin but he wanted somebody to actually test it. - Arnd gave his Ack (So it looked functionally correct to him too) - We can probably push this into linux-next now and see if somebody complains of any breakage it has done. If not we can get it pushed for 3.11. -- viresh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Print instruction when logging unhandled exceptions
It is often useful to see the instruction that caused an unhandled
exception.
Signed-off-by: Anton Blanchard an...@samba.org
---
We print all ones if the get_user fails, do we want to go to
the added effort of printing like we do in the oops
code?
Index: b/arch/powerpc/kernel/traps.c
===
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -242,9 +242,9 @@ void _exception(int signr, struct pt_reg
{
siginfo_t info;
const char fmt32[] = KERN_INFO %s[%d]: unhandled signal %d \
- at %08lx nip %08lx lr %08lx code %x\n;
+ at %08lx nip %08lx lr %08lx code %x insn %08x\n;
const char fmt64[] = KERN_INFO %s[%d]: unhandled signal %d \
- at %016lx nip %016lx lr %016lx code %x\n;
+ at %016lx nip %016lx lr %016lx code %x insn %08x\n;
if (!user_mode(regs)) {
die(Exception in kernel mode, regs, signr);
@@ -252,9 +252,14 @@ void _exception(int signr, struct pt_reg
}
if (show_unhandled_signals unhandled_signal(current, signr)) {
+ u32 insn;
+
+ if (get_user(insn, (u32 __user *)(regs-nip)))
+ insn = 0x;
+
printk_ratelimited(regs-msr MSR_64BIT ? fmt64 : fmt32,
current-comm, current-pid, signr,
- addr, regs-nip, regs-link, code);
+ addr, regs-nip, regs-link, code, insn);
}
if (arch_irqs_disabled() !arch_irq_disabled_regs(regs))
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
