* [PATCH] powerpc: Fix build errors with UP configs in HV-style KVM
From: Paul Mackerras @ 2013-04-16 6:28 UTC (permalink / raw)
To: linuxppc-dev
This fixes these errors when building UP with CONFIG_KVM_BOOK3S_64_HV=y:
arch/powerpc/kvm/book3s_hv.c:1855:2: error: implicit declaration of function 'inhibit_secondary_onlining' [-Werror=implicit-function-declaration]
arch/powerpc/kvm/book3s_hv.c:1862:2: error: implicit declaration of function 'uninhibit_secondary_onlining' [-Werror=implicit-function-declaration]
cc1: all warnings being treated as errors
and this error (with CONFIG_KVM_BOOK3S_64=m, or a vmlinux link error
with CONFIG_KVM_BOOK3S_64=y):
ERROR: "smp_send_reschedule" [arch/powerpc/kvm/kvm.ko] undefined!
make[2]: *** [__modpost] Error 1
The fix for the link error is suboptimal; ideally we want a self_ipi()
function from irq.c, connected at least to the MPIC code, to initiate
an IPI to this cpu. The fix here at least lets the code build, and it
will work, just with interrupts being delayed sometimes.
Signed-off-by: Paul Mackerras <paulus@samba.org>
---
arch/powerpc/include/asm/smp.h | 2 ++
arch/powerpc/kvm/book3s_hv_interrupts.S | 6 ++++++
2 files changed, 8 insertions(+)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index 195ce2a..ffbaabe 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -143,6 +143,8 @@ extern void __cpu_die(unsigned int cpu);
/* for UP */
#define hard_smp_processor_id() get_hard_smp_processor_id(0)
#define smp_setup_cpu_maps()
+static inline void inhibit_secondary_onlining(void) {}
+static inline void uninhibit_secondary_onlining(void) {}
#endif /* CONFIG_SMP */
diff --git a/arch/powerpc/kvm/book3s_hv_interrupts.S b/arch/powerpc/kvm/book3s_hv_interrupts.S
index 84035a5..37f1cc4 100644
--- a/arch/powerpc/kvm/book3s_hv_interrupts.S
+++ b/arch/powerpc/kvm/book3s_hv_interrupts.S
@@ -122,11 +122,16 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
add r8,r8,r7
std r8,HSTATE_DECEXP(r13)
+#ifdef CONFIG_SMP
/*
* On PPC970, if the guest vcpu has an external interrupt pending,
* send ourselves an IPI so as to interrupt the guest once it
* enables interrupts. (It must have interrupts disabled,
* otherwise we would already have delivered the interrupt.)
+ *
+ * XXX If this is a UP build, smp_send_reschedule is not available,
+ * so the interrupt will be delayed until the next time the vcpu
+ * enters the guest with interrupts enabled.
*/
BEGIN_FTR_SECTION
ld r0, VCPU_PENDING_EXC(r4)
@@ -141,6 +146,7 @@ BEGIN_FTR_SECTION
mr r4, r31
32:
END_FTR_SECTION_IFSET(CPU_FTR_ARCH_201)
+#endif /* CONFIG_SMP */
/* Jump to partition switch code */
bl .kvmppc_hv_entry_trampoline
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH 5/8] Read rtas partition via pstore
From: Aruna Balakrishnaiah @ 2013-04-16 6:21 UTC (permalink / raw)
To: Michael Ellerman
Cc: jkenisto, mahesh, linux-kernel, linuxppc-dev, paulus, anton
In-Reply-To: <20130415080101.GF30156@concordia>
On Monday 15 April 2013 01:31 PM, Michael Ellerman wrote:
> On Wed, Apr 10, 2013 at 12:53:27PM +0530, Aruna Balakrishnaiah wrote:
>> This patch exploits pstore infrastructure to read the details
>> from NVRAM's rtas partition.
> Does that mean it's exposed in the pstore filesystem?
Yeah thats right.
>> Signed-off-by: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
>> Reviewed-by: Jim Keniston <jkenisto@us.ibm.com>
>> ---
>> arch/powerpc/platforms/pseries/nvram.c | 33 +++++++++++++++++++++++++-------
>> fs/pstore/inode.c | 3 +++
>> include/linux/pstore.h | 2 ++
>> 3 files changed, 31 insertions(+), 7 deletions(-)
>>
>> diff --git a/arch/powerpc/platforms/pseries/nvram.c b/arch/powerpc/platforms/pseries/nvram.c
>> index 82d32a2..d420b1d 100644
>> --- a/arch/powerpc/platforms/pseries/nvram.c
>> +++ b/arch/powerpc/platforms/pseries/nvram.c
>> @@ -144,9 +144,11 @@ static size_t oops_data_sz;
>> #ifdef CONFIG_PSTORE
>> static enum pstore_type_id nvram_type_ids[] = {
>> PSTORE_TYPE_DMESG,
>> + PSTORE_TYPE_RTAS,
>> -1
>> };
>> static int read_type;
>> +static unsigned long last_rtas_event;
>> #endif
>> /* Compression parameters */
>> #define COMPR_LEVEL 6
>> @@ -315,8 +317,13 @@ int nvram_write_error_log(char * buff, int length,
>> {
>> int rc = nvram_write_os_partition(&rtas_log_partition, buff, length,
>> err_type, error_log_cnt);
>> - if (!rc)
>> + if (!rc) {
>> last_unread_rtas_event = get_seconds();
>> +#ifdef CONFIG_PSTORE
>> + last_rtas_event = get_seconds();
>> +#endif
>> + }
>> +
>> return rc;
>> }
>>
>> @@ -745,7 +752,7 @@ static int nvram_pstore_write(enum pstore_type_id type,
>> }
>>
>> /*
>> - * Reads the oops/panic report.
>> + * Reads the oops/panic report and ibm,rtas-log partition.
>> * Returns the length of the data we read from each partition.
>> * Returns 0 if we've been called before.
>> */
>> @@ -765,6 +772,12 @@ static ssize_t nvram_pstore_read(u64 *id, enum pstore_type_id *type,
>> part = &oops_log_partition;
>> *type = PSTORE_TYPE_DMESG;
>> break;
>> + case PSTORE_TYPE_RTAS:
>> + part = &rtas_log_partition;
>> + *type = PSTORE_TYPE_RTAS;
>> + time->tv_sec = last_rtas_event;
>> + time->tv_nsec = 0;
>> + break;
>> default:
>> return 0;
>> }
>> @@ -781,11 +794,17 @@ static ssize_t nvram_pstore_read(u64 *id, enum pstore_type_id *type,
>>
>> *count = 0;
>> *id = id_no;
>> - oops_hdr = (struct oops_log_info *)buff;
>> - *buf = buff + sizeof(*oops_hdr);
>> - time->tv_sec = oops_hdr->timestamp;
>> - time->tv_nsec = 0;
>> - return oops_hdr->report_length;
>> +
>> + if (nvram_type_ids[read_type] == PSTORE_TYPE_DMESG) {
>> + oops_hdr = (struct oops_log_info *)buff;
>> + *buf = buff + sizeof(*oops_hdr);
>> + time->tv_sec = oops_hdr->timestamp;
>> + time->tv_nsec = 0;
>> + return oops_hdr->report_length;
>> + }
>> +
>> + *buf = buff;
>> + return part->size;
>> }
>> #else
>> static int nvram_pstore_open(struct pstore_info *psi)
>> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
>> index e4bcb2c..59b1454 100644
>> --- a/fs/pstore/inode.c
>> +++ b/fs/pstore/inode.c
>> @@ -324,6 +324,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
>> case PSTORE_TYPE_MCE:
>> sprintf(name, "mce-%s-%lld", psname, id);
>> break;
>> + case PSTORE_TYPE_RTAS:
>> + sprintf(name, "rtas-%s-%lld", psname, id);
>> + break;
>> case PSTORE_TYPE_UNKNOWN:
>> sprintf(name, "unknown-%s-%lld", psname, id);
>> break;
>> diff --git a/include/linux/pstore.h b/include/linux/pstore.h
>> index 75d0176..4eb94c9 100644
>> --- a/include/linux/pstore.h
>> +++ b/include/linux/pstore.h
>> @@ -35,6 +35,8 @@ enum pstore_type_id {
>> PSTORE_TYPE_MCE = 1,
>> PSTORE_TYPE_CONSOLE = 2,
>> PSTORE_TYPE_FTRACE = 3,
>> + /* PPC64 partition types */
>> + PSTORE_TYPE_RTAS = 10,
>> PSTORE_TYPE_UNKNOWN = 255
> I think you should probably just continue at 4, and call it
> PSTORE_TYPE_PPC_RTAS. But you must get an ACK from the pstore
> maintainers for this and the previous hunk, and I don't see them on CC.
Sure, will add them on cc in my next version of the patches.
>
> cheers
>
^ permalink raw reply
* Re: [PATCH 4/8] Read/Write oops nvram partition via pstore
From: Aruna Balakrishnaiah @ 2013-04-16 6:20 UTC (permalink / raw)
To: Michael Ellerman
Cc: jkenisto, mahesh, linux-kernel, linuxppc-dev, paulus, anton
In-Reply-To: <20130415075555.GE30156@concordia>
Hi Michael,
Thanks for reviewing my patches.
On Monday 15 April 2013 01:25 PM, Michael Ellerman wrote:
> On Wed, Apr 10, 2013 at 12:53:03PM +0530, Aruna Balakrishnaiah wrote:
>> This patch exploits pstore infrastructure in power systems.
>> IBM's system p machines provide persistent storage for LPARs
> In the kernel we use "pseries" instead of "system p".
>
Sure, will change it.
>> through NVRAM. NVRAM's lnx,oops-log partition is used to log
>> oops messages. In case pstore registration fails it will
>> fall back to kmsg_dump mechanism.
> What are the implications of falling back to kmsg_dump()?
>
Logging oops messages to nvram should not fail in case pstore registration
fails. So it falls back to existing kmsg_dump infrastructure where
oops_to_nvram will be called. The users would need to use existing tools
to read nvram data as it is now.
> Is there any reason we would not want to enable CONFIG_PSTORE ? ie.
> should the pseries platform just select it?
Since current patchset does not support compression, selecting PSTORE by
default will lose the existing compression feature.
Once the compression feature for PSTORE is in place we can make PSTORE as
default on power.
I will post the compression patches soon. The reason for posting it
separately is stated below.
>> diff --git a/arch/powerpc/platforms/pseries/nvram.c b/arch/powerpc/platforms/pseries/nvram.c
>> index 6701b71..82d32a2 100644
>> --- a/arch/powerpc/platforms/pseries/nvram.c
>> +++ b/arch/powerpc/platforms/pseries/nvram.c
>> @@ -18,6 +18,7 @@
>> #include <linux/spinlock.h>
>> #include <linux/slab.h>
>> #include <linux/kmsg_dump.h>
>> +#include <linux/pstore.h>
>> #include <linux/ctype.h>
>> #include <linux/zlib.h>
>> #include <asm/uaccess.h>
>> @@ -87,6 +88,25 @@ static struct kmsg_dumper nvram_kmsg_dumper = {
>> .dump = oops_to_nvram
>> };
>>
>> +static int nvram_pstore_open(struct pstore_info *psi);
>> +
>> +static ssize_t nvram_pstore_read(u64 *id, enum pstore_type_id *type,
>> + int *count, struct timespec *time, char **buf,
>> + struct pstore_info *psi);
>> +
>> +static int nvram_pstore_write(enum pstore_type_id type,
>> + enum kmsg_dump_reason reason, u64 *id,
>> + unsigned int part, int count, size_t size,
>> + struct pstore_info *psi);
> I think you should be able to rearrange this so that you don't need the
> forward declarations.
Sure. This would result in moving the callback functions just before pstore
registration for which I need to move clobbering_unread_rtas_event() which
is used by nvram_pstore_write.
>> +
>> +static struct pstore_info nvram_pstore_info = {
>> + .owner = THIS_MODULE,
>> + .name = "nvram",
>> + .open = nvram_pstore_open,
>> + .read = nvram_pstore_read,
>> + .write = nvram_pstore_write,
>> +};
>> +
>> /* See clobbering_unread_rtas_event() */
>> #define NVRAM_RTAS_READ_TIMEOUT 5 /* seconds */
>> static unsigned long last_unread_rtas_event; /* timestamp */
>> @@ -121,6 +141,13 @@ static char *big_oops_buf, *oops_buf;
>> static char *oops_data;
>> static size_t oops_data_sz;
>>
>> +#ifdef CONFIG_PSTORE
> If we are going to have CONFIG_PSTORE #ifdefs in this file, I don't see
> why there can't be just a single block of code that is #ifdef'ed, rather
> than several like you have.
Sure. I will have one #ifdef for declarations and one for function
definitions.
>> +static enum pstore_type_id nvram_type_ids[] = {
>> + PSTORE_TYPE_DMESG,
>> + -1
>> +};
>> +static int read_type;
> I don't understand what you're doing with read_type. It looks fishy.
read_type is an iterator to traverse the partition types. It is to know
which partition we need to read.
>> +#endif
>> /* Compression parameters */
>> #define COMPR_LEVEL 6
>> #define WINDOW_BITS 12
>> @@ -455,6 +482,23 @@ static void __init nvram_init_oops_partition(int rtas_partition_exists)
>> oops_data = oops_buf + sizeof(struct oops_log_info);
>> oops_data_sz = oops_log_partition.size - sizeof(struct oops_log_info);
>>
>> + nvram_pstore_info.buf = oops_data;
>> + nvram_pstore_info.bufsize = oops_data_sz;
>> +
>> + rc = pstore_register(&nvram_pstore_info);
>> +
>> + if (rc != 0) {
>> + pr_err("nvram: pstore_register() failed, defaults to "
>> + "kmsg_dump; returned %d\n", rc);
>> + goto kmsg_dump;
> You don't need the goto.
Yeah, my bad. Will fix it.
>> + } else {
>> + /*TODO: Support compression when pstore is configured */
> What is the issue here?
>
Currently with this patchset, pstore is not supporting compression of oops-messages
since it involves some changes in the pstore framework.
big_oops_buf will hold the large part of oops data which will be compressed and put
to oops_buf.
big_oops_buf: (1.45 of oops_partition_size)
_________________________
| header | oops-text |
|_________|_____________|
<header> is added by the pstore.
So in case compression fails:
we would need to log the header + last few bytes of big_oops_buf to oops_buf.
oops_buf: (this is of oops_partition_size)
we need last few bytes of big_oops_buf as we need to log the recent messages of
printk buffer. For which we need to know the header size and it involves some
changes in the pstore framework.
I have the compression patches ready, will be posting it soon as a separate set.
>> + pr_info("nvram: Compression of oops text supported only when "
>> + "pstore is not configured");
>> + return;
>> + }
>> +
>> +kmsg_dump:
>> /*
>> * Figure compression (preceded by elimination of each line's <n>
>> * severity prefix) will reduce the oops/panic report to at most
>> @@ -663,3 +707,104 @@ static void oops_to_nvram(struct kmsg_dumper *dumper,
>>
>> spin_unlock_irqrestore(&lock, flags);
>> }
>> +
>> +#ifdef CONFIG_PSTORE
> Same comment about too many ifdefs.
>
I will reduce some of the #ifdefs, but its necessary to have one for
declarations and one for function definitions.
For instance: nvram_pstore_write calls nvram_write_os_partition.
So callback function definitions should be after some of the function
definitions which it will make use of.
>> +static int nvram_pstore_open(struct pstore_info *psi)
>> +{
>> + read_type = -1;
> Locking?
We need to reset read_type for a remount case. When a umount and mount
is done nvram_pstore_read needs to know that it has to start reading
the partitions again. So we reset the iterator.
>> + return 0;
>> +}
>> +
>> +/*
> Make it a kernel-doc style comment.
Sure.
>> + * Called by pstore_dump() when an oops or panic report is logged to the printk
>> + * buffer. @size bytes have been written to oops_buf, starting after the
>> + * oops_log_info header.
> "@size bytes have", or "@size bytes should be written"?
Sure.
>> + */
>> +static int nvram_pstore_write(enum pstore_type_id type,
>> + enum kmsg_dump_reason reason,
>> + u64 *id, unsigned int part, int count,
>> + size_t size, struct pstore_info *psi)
>> +{
>> + struct oops_log_info *oops_hdr = (struct oops_log_info *) oops_buf;
>> +
>> + /* part 1 has the recent messages from printk buffer */
>> + if (part > 1 || clobbering_unread_rtas_event())
>> + return -1;
>> +
>> + BUG_ON(type != PSTORE_TYPE_DMESG);
>> + BUG_ON(sizeof(*oops_hdr) + size > oops_log_partition.size);
> Why would we be called with the wrong type? Would it be better to just
> return an error, rather than causing another oops while we're trying to
> write the oops?
>
> And couldn't we just clamp the size, rather than BUG'ing.
Yeah right. Will return an error instead of bugging here.
>> + oops_hdr->version = OOPS_HDR_VERSION;
>> + oops_hdr->report_length = (u16) size;
>> + oops_hdr->timestamp = get_seconds();
>> + (void) nvram_write_os_partition(&oops_log_partition, oops_buf,
>> + (int) (sizeof(*oops_hdr) + size), ERR_TYPE_KERNEL_PANIC,
>> + count);
> You definitely don't need the (void). But more to the point why aren't
> you checking the return value?
I will check for the return value here.
>> + *id = part;
> What is this? Part of the API?
Yeah this is part of the API.
>> + return 0;
>> +}
>> +
>> +/*
>> + * Reads the oops/panic report.
>> + * Returns the length of the data we read from each partition.
>> + * Returns 0 if we've been called before.
>> + */
>> +static ssize_t nvram_pstore_read(u64 *id, enum pstore_type_id *type,
>> + int *count, struct timespec *time, char **buf,
>> + struct pstore_info *psi)
>> +{
>> + struct oops_log_info *oops_hdr;
>> + unsigned int err_type, id_no;
>> + struct nvram_os_partition *part = NULL;
>> + char *buff = NULL;
>> +
>> + read_type++;
>> +
>> + switch (nvram_type_ids[read_type]) {
>> + case PSTORE_TYPE_DMESG:
>> + part = &oops_log_partition;
>> + *type = PSTORE_TYPE_DMESG;
>> + break;
>> + default:
>> + return 0;
>> + }
>> +
>> + buff = kmalloc(part->size, GFP_KERNEL);
>> +
>> + if (!buff)
>> + return -ENOMEM;
>> +
>> + if (nvram_read_partition(part, buff, part->size, &err_type, &id_no)) {
>> + kfree(buff);
>> + return 0;
>> + }
>> +
>> + *count = 0;
>> + *id = id_no;
> Can't you just cast in the call to nvram_read_partition() ?
Thats right, my bad will fix it.
>> + oops_hdr = (struct oops_log_info *)buff;
>> + *buf = buff + sizeof(*oops_hdr);
>> + time->tv_sec = oops_hdr->timestamp;
>> + time->tv_nsec = 0;
>> + return oops_hdr->report_length;
>> +}
>> +#else
>> +static int nvram_pstore_open(struct pstore_info *psi)
>> +{
>> + return 0;
>> +}
>> +
>> +static int nvram_pstore_write(enum pstore_type_id type,
>> + enum kmsg_dump_reason reason, u64 *id,
>> + unsigned int part, int count, size_t size,
>> + struct pstore_info *psi)
>> +{
>> + return 0;
>> +}
>> +
>> +static ssize_t nvram_pstore_read(u64 *id, enum pstore_type_id *type,
>> + int *count, struct timespec *time, char **buf,
>> + struct pstore_info *psi)
>> +{
>> + return 0;
>> +}
>> +#endif
> I don't understand why we have empty versions of these. If CONFIG_PSTORE
> is disabled we should just not register with pstore at all.
Since pstore handles the case by returning an error code when pstore is not
configured I thought of avoiding one more #ifdef during registration.
I will remove empty callbacks and add a #ifdef during registration itself.
> cheers
>
^ permalink raw reply
* Re: [PATCH] powerpc: Fix audit crash due to save/restore PPR changes
From: Haren Myneni @ 2013-04-16 5:38 UTC (permalink / raw)
To: Alistair Popple; +Cc: sfr, mikey, linuxppc-dev
In-Reply-To: <18949a6b246ced7268c2d2831f931f01.squirrel@mignight.com>
On 04/14/2013 06:44 PM, Alistair Popple wrote:
> The current mainline crashes when hitting userspace with the following:
>
> kernel BUG at /home/alistair/Source/linux-stable/kernel/auditsc.c:1769!
> cpu 0x1: Vector: 700 (Program Check) at [c000000023883a60]
> pc: c0000000001047a8: .__audit_syscall_entry+0x38/0x130
> lr: c00000000000ed64: .do_syscall_trace_enter+0xc4/0x270
> sp: c000000023883ce0
> msr: 8000000000029032
> current = 0xc000000023800000
> paca = 0xc00000000f080380 softe: 0 irq_happened: 0x01
> pid = 1629, comm = start_udev
> kernel BUG at /home/alistair/Source/linux-stable/kernel/auditsc.c:1769!
> enter ? for help
> [c000000023883d80] c00000000000ed64 .do_syscall_trace_enter+0xc4/0x270
> [c000000023883e30] c000000000009b08 syscall_dotrace+0xc/0x38
> --- Exception: c00 (System Call) at 0000008010ec50dc
>
> Bisecting found the following patch caused it:
>
> commit 44e9309f1f357794b7ae93d5f3e3e6f11d2b8a7f
> Author: Haren Myneni <haren@linux.vnet.ibm.com>
> powerpc: Implement PPR save/restore
>
> It was found this patch corrupted r9 when calling
> SET_DEFAULT_THREAD_PPR()
>
> Using r10 as a scratch register instead of r9 solved the problem.
Thanks for fixing. Sorry I missed it
Acked-by: Haren Myneni <haren@us.ibm.com>
>
> Signed-off-by: Alistair Popple <alistair@popple.id.au>
> Acked-by: Michael Neuling <mikey@neuling.org>
> ---
>
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 256c5bf..3acb1a0 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -304,7 +304,7 @@ syscall_exit_work:
> subi r12,r12,TI_FLAGS
>
> 4: /* Anything else left to do? */
> - SET_DEFAULT_THREAD_PPR(r3, r9) /* Set thread.ppr = 3 */
> + SET_DEFAULT_THREAD_PPR(r3, r10) /* Set thread.ppr = 3 */
> andi. r0,r9,(_TIF_SYSCALL_T_OR_A|_TIF_SINGLESTEP)
> beq .ret_from_except_lite
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
^ permalink raw reply
* Re: [PATCHv3 2/2] radeon: use max_bus_speed to activate gen2 speeds
From: Dave Airlie @ 2013-04-16 3:17 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: DRI mailing list, Kleber Sacilotto de Souza, Brian King,
Jerome Glisse, Thadeu Lima de Souza Cascardo,
Lucas Kannebley Tavares, Alex Deucher, linuxppc-dev
In-Reply-To: <CAErSpo7vxSJix83DQcsARPWYWbx8UGxQ9FN61OtEJrEv7GhK=g@mail.gmail.com>
>>
>> diff --git a/drivers/gpu/drm/radeon/evergreen.c b/drivers/gpu/drm/radeon/evergreen.c
>> index 305a657..3291f62 100644
>> --- a/drivers/gpu/drm/radeon/evergreen.c
>> +++ b/drivers/gpu/drm/radeon/evergreen.c
>> @@ -3855,8 +3855,7 @@ void evergreen_fini(struct radeon_device *rdev)
>>
>> void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
>> {
>> - u32 link_width_cntl, speed_cntl, mask;
>> - int ret;
>> + u32 link_width_cntl, speed_cntl;
>>
>> if (radeon_pcie_gen2 == 0)
>> return;
>> @@ -3871,11 +3870,7 @@ void evergreen_pcie_gen2_enable(struct radeon_device *rdev)
>> if (ASIC_IS_X2(rdev))
>> return;
>>
>> - ret = drm_pcie_get_speed_cap_mask(rdev->ddev, &mask);
>> - if (ret != 0)
>> - return;
>> -
>> - if (!(mask & DRM_PCIE_SPEED_50))
>> + if (rdev->pdev->bus->max_bus_speed < PCIE_SPEED_5_0GT)
>
> For devices on a root bus, we previously dereferenced a NULL pointer
> in drm_pcie_get_speed_cap_mask() because pdev->bus->self is NULL on a
> root bus. (I think this is the original problem you tripped over,
> Lucas.)
>
> These patches fix that problem. On pseries, where the device *is* on
> a root bus, your patches set max_bus_speed so this will work as
> expected. On most other systems, max_bus_speed for root buses will be
> PCI_SPEED_UNKNOWN (set in pci_alloc_bus() and never updated because
> most arches don't have code like the pseries code you're adding).
>
> PCI_SPEED_UNKNOWN = 0xff, so if we see another machine with a GPU on
> the root bus, we'll attempt to enable Gen2 on the device even though
> we have no idea what the bus will support.
>
> That's why I originally suggested skipping the Gen2 stuff if
> "max_bus_speed == PCI_SPEED_UNKNOWN". I was just being conservative,
> thinking that it's better to have a functional but slow GPU rather
> than the unknown (to me) effects of enabling Gen2 on a link that might
> not support it. But I'm fine with this being either way.
>
> It would be nice if we could get rid of drm_pcie_get_speed_cap_mask()
> altogether. It is exported, but I have no idea of anybody else uses
> it. Maybe it could at least be marked __deprecated now?
>
> I don't know who should take these patches. They don't touch
> drivers/pci, but I'd be happy to push them, given the appropriate ACKs
> from DRM and powerpc folks.
>
Acked-by: Dave Airlie <airlied@redhat.com>
I'm happy to see these go via pci tree to avoid interdependent trees.
Dave.
^ permalink raw reply
* [RFC PATCH v3 3/3] powerpc: Try to insert the hptes repeatedly in kernel_map_linear_page()
From: Li Zhong @ 2013-04-16 2:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, Li Zhong
In-Reply-To: <1366080800-27885-1-git-send-email-zhong@linux.vnet.ibm.com>
This patch fixes the following oops, which could be trigged by build the kernel
with many concurrent threads, under CONFIG_DEBUG_PAGEALLOC.
hpte_insert() might return -1, indicating that the bucket (primary here)
is full. We are not necessarily reporting a BUG in this case. Instead, we could
try repeatedly (try secondary, remove and try again) until we find a slot.
[ 543.075675] ------------[ cut here ]------------
[ 543.075701] kernel BUG at arch/powerpc/mm/hash_utils_64.c:1239!
[ 543.075714] Oops: Exception in kernel mode, sig: 5 [#1]
[ 543.075722] PREEMPT SMP NR_CPUS=16 DEBUG_PAGEALLOC NUMA pSeries
[ 543.075741] Modules linked in: binfmt_misc ehea
[ 543.075759] NIP: c000000000036eb0 LR: c000000000036ea4 CTR: c00000000005a594
[ 543.075771] REGS: c0000000a90832c0 TRAP: 0700 Not tainted (3.8.0-next-20130222)
[ 543.075781] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 22224482 XER: 00000000
[ 543.075816] SOFTE: 0
[ 543.075823] CFAR: c00000000004c200
[ 543.075830] TASK = c0000000e506b750[23934] 'cc1' THREAD: c0000000a9080000 CPU: 1
GPR00: 0000000000000001 c0000000a9083540 c000000000c600a8 ffffffffffffffff
GPR04: 0000000000000050 fffffffffffffffa c0000000a90834e0 00000000004ff594
GPR08: 0000000000000001 0000000000000000 000000009592d4d8 c000000000c86854
GPR12: 0000000000000002 c000000006ead300 0000000000a51000 0000000000000001
GPR16: f000000003354380 ffffffffffffffff ffffffffffffff80 0000000000000000
GPR20: 0000000000000001 c000000000c600a8 0000000000000001 0000000000000001
GPR24: 0000000003354380 c000000000000000 0000000000000000 c000000000b65950
GPR28: 0000002000000000 00000000000cd50e 0000000000bf50d9 c000000000c7c230
[ 543.076005] NIP [c000000000036eb0] .kernel_map_pages+0x1e0/0x3f8
[ 543.076016] LR [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8
[ 543.076025] Call Trace:
[ 543.076033] [c0000000a9083540] [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8 (unreliable)
[ 543.076053] [c0000000a9083640] [c000000000167638] .get_page_from_freelist+0x6cc/0x8dc
[ 543.076067] [c0000000a9083800] [c000000000167a48] .__alloc_pages_nodemask+0x200/0x96c
[ 543.076082] [c0000000a90839c0] [c0000000001ade44] .alloc_pages_vma+0x160/0x1e4
[ 543.076098] [c0000000a9083a80] [c00000000018ce04] .handle_pte_fault+0x1b0/0x7e8
[ 543.076113] [c0000000a9083b50] [c00000000018d5a8] .handle_mm_fault+0x16c/0x1a0
[ 543.076129] [c0000000a9083c00] [c0000000007bf1dc] .do_page_fault+0x4d0/0x7a4
[ 543.076144] [c0000000a9083e30] [c0000000000090e8] handle_page_fault+0x10/0x30
[ 543.076155] Instruction dump:
[ 543.076163] 7c630038 78631d88 e80a0000 f8410028 7c0903a6 e91f01de e96a0010 e84a0008
[ 543.076192] 4e800421 e8410028 7c7107b4 7a200fe0 <0b000000> 7f63db78 48785781 60000000
[ 543.076224] ---[ end trace bd5807e8d6ae186b ]---
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index ead9fa8..1ed4419 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1268,21 +1268,22 @@ repeat:
#ifdef CONFIG_DEBUG_PAGEALLOC
static void kernel_map_linear_page(unsigned long vaddr, unsigned long lmi)
{
- unsigned long hash, hpteg;
+ unsigned long hash;
unsigned long vsid = get_kernel_vsid(vaddr, mmu_kernel_ssize);
unsigned long vpn = hpt_vpn(vaddr, vsid, mmu_kernel_ssize);
unsigned long mode = htab_convert_pte_flags(PAGE_KERNEL);
- int ret;
+ long ret;
hash = hpt_hash(vpn, PAGE_SHIFT, mmu_kernel_ssize);
- hpteg = ((hash & htab_hash_mask) * HPTES_PER_GROUP);
/* Don't create HPTE entries for bad address */
if (!vsid)
return;
- ret = ppc_md.hpte_insert(hpteg, vpn, __pa(vaddr),
- mode, HPTE_V_BOLTED,
- mmu_linear_psize, mmu_kernel_ssize);
+
+ ret = hpte_insert_repeating(hash, vpn, __pa(vaddr), mode,
+ HPTE_V_BOLTED,
+ mmu_linear_psize, mmu_kernel_ssize);
+
BUG_ON (ret < 0);
spin_lock(&linear_map_hash_lock);
BUG_ON(linear_map_hash_slots[lmi] & 0x80);
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v3 2/3] powerpc: Split the code trying to insert hpte repeatedly as an helper function
From: Li Zhong @ 2013-04-16 2:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, Li Zhong
In-Reply-To: <1366080800-27885-1-git-send-email-zhong@linux.vnet.ibm.com>
Move the logic trying to insert hpte in __hash_page_huge() to an helper
function, so it could also be used by others.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/mm/hash_utils_64.c | 35 ++++++++++++++++++++++++++++++++++
arch/powerpc/mm/hugetlbpage-hash64.c | 31 ++++++------------------------
2 files changed, 41 insertions(+), 25 deletions(-)
diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
index f410c3e..ead9fa8 100644
--- a/arch/powerpc/mm/hash_utils_64.c
+++ b/arch/powerpc/mm/hash_utils_64.c
@@ -1230,6 +1230,41 @@ void low_hash_fault(struct pt_regs *regs, unsigned long address, int rc)
bad_page_fault(regs, address, SIGBUS);
}
+long hpte_insert_repeating(unsigned long hash, unsigned long vpn,
+ unsigned long pa, unsigned long rflags,
+ unsigned long vflags, int psize, int ssize)
+{
+ unsigned long hpte_group;
+ long slot;
+
+repeat:
+ hpte_group = ((hash & htab_hash_mask) *
+ HPTES_PER_GROUP) & ~0x7UL;
+
+ /* Insert into the hash table, primary slot */
+ slot = ppc_md.hpte_insert(hpte_group, vpn, pa, rflags, vflags,
+ psize, ssize);
+
+ /* Primary is full, try the secondary */
+ if (unlikely(slot == -1)) {
+ hpte_group = ((~hash & htab_hash_mask) *
+ HPTES_PER_GROUP) & ~0x7UL;
+ slot = ppc_md.hpte_insert(hpte_group, vpn, pa, rflags,
+ vflags | HPTE_V_SECONDARY,
+ psize, ssize);
+ if (slot == -1) {
+ if (mftb() & 0x1)
+ hpte_group = ((hash & htab_hash_mask) *
+ HPTES_PER_GROUP)&~0x7UL;
+
+ ppc_md.hpte_remove(hpte_group);
+ goto repeat;
+ }
+ }
+
+ return slot;
+}
+
#ifdef CONFIG_DEBUG_PAGEALLOC
static void kernel_map_linear_page(unsigned long vaddr, unsigned long lmi)
{
diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c b/arch/powerpc/mm/hugetlbpage-hash64.c
index edb4129..b913f41 100644
--- a/arch/powerpc/mm/hugetlbpage-hash64.c
+++ b/arch/powerpc/mm/hugetlbpage-hash64.c
@@ -14,6 +14,10 @@
#include <asm/cacheflush.h>
#include <asm/machdep.h>
+extern long hpte_insert_repeating(unsigned long hash, unsigned long vpn,
+ unsigned long pa, unsigned long rlags,
+ unsigned long vflags, int psize, int ssize);
+
int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
pte_t *ptep, unsigned long trap, int local, int ssize,
unsigned int shift, unsigned int mmu_psize)
@@ -83,7 +87,6 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
if (likely(!(old_pte & _PAGE_HASHPTE))) {
unsigned long hash = hpt_hash(vpn, shift, ssize);
- unsigned long hpte_group;
pa = pte_pfn(__pte(old_pte)) << PAGE_SHIFT;
@@ -97,30 +100,8 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
rflags |= (new_pte & (_PAGE_WRITETHRU | _PAGE_NO_CACHE |
_PAGE_COHERENT | _PAGE_GUARDED));
-repeat:
- hpte_group = ((hash & htab_hash_mask) *
- HPTES_PER_GROUP) & ~0x7UL;
-
- /* Insert into the hash table, primary slot */
- slot = ppc_md.hpte_insert(hpte_group, vpn, pa, rflags, 0,
- mmu_psize, ssize);
-
- /* Primary is full, try the secondary */
- if (unlikely(slot == -1)) {
- hpte_group = ((~hash & htab_hash_mask) *
- HPTES_PER_GROUP) & ~0x7UL;
- slot = ppc_md.hpte_insert(hpte_group, vpn, pa, rflags,
- HPTE_V_SECONDARY,
- mmu_psize, ssize);
- if (slot == -1) {
- if (mftb() & 0x1)
- hpte_group = ((hash & htab_hash_mask) *
- HPTES_PER_GROUP)&~0x7UL;
-
- ppc_md.hpte_remove(hpte_group);
- goto repeat;
- }
- }
+ slot = hpte_insert_repeating(hash, vpn, pa, rflags, 0,
+ mmu_psize, ssize);
/*
* Hypervisor failure. Restore old pte and return -1
--
1.7.9.5
^ permalink raw reply related
* [RFC PATCH v3 1/3] powerpc: Move the setting of rflags out of loop in __hash_page_huge
From: Li Zhong @ 2013-04-16 2:53 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, Li Zhong
It seems that new_pte and rflags don't get changed in the repeating loop, so
move their assignment out of the loop.
Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
---
arch/powerpc/mm/hugetlbpage-hash64.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c b/arch/powerpc/mm/hugetlbpage-hash64.c
index cecad34..edb4129 100644
--- a/arch/powerpc/mm/hugetlbpage-hash64.c
+++ b/arch/powerpc/mm/hugetlbpage-hash64.c
@@ -87,10 +87,6 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
pa = pte_pfn(__pte(old_pte)) << PAGE_SHIFT;
-repeat:
- hpte_group = ((hash & htab_hash_mask) *
- HPTES_PER_GROUP) & ~0x7UL;
-
/* clear HPTE slot informations in new PTE */
#ifdef CONFIG_PPC_64K_PAGES
new_pte = (new_pte & ~_PAGE_HPTEFLAGS) | _PAGE_HPTE_SUB0;
@@ -101,6 +97,10 @@ repeat:
rflags |= (new_pte & (_PAGE_WRITETHRU | _PAGE_NO_CACHE |
_PAGE_COHERENT | _PAGE_GUARDED));
+repeat:
+ hpte_group = ((hash & htab_hash_mask) *
+ HPTES_PER_GROUP) & ~0x7UL;
+
/* Insert into the hash table, primary slot */
slot = ppc_md.hpte_insert(hpte_group, vpn, pa, rflags, 0,
mmu_psize, ssize);
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC PATCH v2 3/4] powerpc: Don't bolt the hpte in kernel_map_linear_page()
From: Li Zhong @ 2013-04-16 2:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1366025246.24994.35.camel@pasglop>
On Mon, 2013-04-15 at 13:27 +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-15 at 16:15 +0800, Li Zhong wrote:
>
> > So the code is implemented in ppc_md.hpte_remove(), may be called by
> > __hash_huge_page(), and asm code htab_call_hpte_remove?
> >
> > > This is why the linear mapping (and the vmemmap) must be bolted.
> >
> > If not, it would result the infinite recursion like above?
>
> Potentially, we don't expect to fault linear mapping or vmemmap entries
> on demand. We aren't equipped to do it and we occasionally have code
> path that access the linear mapping and cannot afford to have SRR0 and
> SRR1 clobbered by a page fault.
Thank you for the education :)
Thanks, Zhong
>
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH v2 2/11] Add PRRN Event Handler
From: Nathan Fontenot @ 2013-04-15 20:12 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20130410083012.GD24786@concordia>
On 04/10/2013 03:30 AM, Michael Ellerman wrote:
> On Mon, Mar 25, 2013 at 01:52:32PM -0500, Nathan Fontenot wrote:
>> From: Jesse Larrew <jlarrew@linux.vnet.ibm.com>
>>
>> A PRRN event is signaled via the RTAS event-scan mechanism, which
>> returns a Hot Plug Event message "fixed part" indicating "Platform
>> Resource Reassignment". In response to the Hot Plug Event message,
>> we must call ibm,update-nodes to determine which resources were
>> reassigned and then ibm,update-properties to obtain the new affinity
>> information about those resources.
> ..
>
>> Index: powerpc/arch/powerpc/kernel/rtasd.c
>> ===================================================================
>> --- powerpc.orig/arch/powerpc/kernel/rtasd.c 2013-03-20 08:24:14.000000000 -0500
>> +++ powerpc/arch/powerpc/kernel/rtasd.c 2013-03-20 08:52:08.000000000 -0500
>> @@ -87,6 +87,8 @@
>> return "Resource Deallocation Event";
>> case RTAS_TYPE_DUMP:
>> return "Dump Notification Event";
>> + case RTAS_TYPE_PRRN:
>> + return "Platform Resource Reassignment Event";
>> }
>>
>> return rtas_type[0];
>> @@ -265,7 +267,38 @@
>> spin_unlock_irqrestore(&rtasd_log_lock, s);
>> return;
>> }
>> +}
>> +
>> +static s32 update_scope;
>> +
>> +static void prrn_work_fn(struct work_struct *work)
>> +{
>> + /*
>> + * For PRRN, we must pass the negative of the scope value in
>> + * the RTAS event.
>> + */
>> + pseries_devicetree_update(-update_scope);
>> +}
>> +static DECLARE_WORK(prrn_work, prrn_work_fn);
>
> This breaks the 32-bit build (ppc6xx_defconfig):
>
> arch/powerpc/kernel/rtasd.c:280: undefined reference to `pseries_devicetree_update'
>
I'm not seeing this error. rtasd.c compilkes fine, but I am hitting another
error later in the build that keeps it from finishing.
arch/powerpc/platforms/52xx/mpc52xx_pic.c: In function ‘mpc52xx_irqhost_map’:
arch/powerpc/platforms/52xx/mpc52xx_pic.c:343: error: ‘irqchip’ may be used uninitialized in this function
-Nathan
^ permalink raw reply
* RE: [PATCH 1/3] iommu: Move swap_pci_ref function to pci.h.
From: Sethi Varun-B16395 @ 2013-04-15 17:13 UTC (permalink / raw)
To: Joerg Roedel
Cc: Wood Scott-B07421, linux-kernel@vger.kernel.org,
Yoder Stuart-B08248, iommu@lists.linux-foundation.org,
bhelgaas@google.com, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20130415145834.GR6858@8bytes.org>
Fine, I will move it to iommu.h.
-Varun
> -----Original Message-----
> From: Joerg Roedel [mailto:joro@8bytes.org]
> Sent: Monday, April 15, 2013 8:29 PM
> To: Sethi Varun-B16395
> Cc: Yoder Stuart-B08248; Wood Scott-B07421; iommu@lists.linux-
> foundation.org; linuxppc-dev@lists.ozlabs.org; linux-
> kernel@vger.kernel.org; galak@kernel.crashing.org;
> benh@kernel.crashing.org; bhelgaas@google.com
> Subject: Re: [PATCH 1/3] iommu: Move swap_pci_ref function to pci.h.
>=20
> On Mon, Apr 15, 2013 at 12:42:00AM +0530, Varun Sethi wrote:
> > swap_pci_ref function is used by the IOMMU API code for swapping pci
> > device pointers, while determining the iommu group for the device.
> > Currently this function was being implemented for different IOMMU
> drivers.
> > This patch moves the function to pci.h so that the implementation can
> > be shared across various IOMMU drivers.
>=20
> The function is only used in IOMMU code, so I think its fine to keep it
> there (unless Bjorn disagrees and wants it in PCI code).
>=20
>=20
> Joerg
>=20
>=20
^ permalink raw reply
* Re: [PATCH] powerpc: fix usage of setup_pci_atmu()
From: Kim Phillips @ 2013-04-15 16:30 UTC (permalink / raw)
To: Michael Neuling; +Cc: sfr, linux-next, linuxppc-dev
In-Reply-To: <5881.1366004521@ale.ozlabs.ibm.com>
On Mon, 15 Apr 2013 15:42:01 +1000
Michael Neuling <mikey@neuling.org> wrote:
> Linux next is currently failing to compile mpc85xx_defconfig with:
> arch/powerpc/sysdev/fsl_pci.c:944:2: error: too many arguments to function 'setup_pci_atmu'
>
> This is caused by (from Kumar's next branch):
> commit 34642bbb3d12121333efcf4ea7dfe66685e403a1
> Author: Kumar Gala <galak@kernel.crashing.org>
> powerpc/fsl-pci: Keep PCI SoC controller registers in pci_controller
>
> Which changed definition of setup_pci_atmu() but didn't update one of
> the callers. Below fixes this.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> ---
> Kumar: this is for your next tree
Reviewed-by: Kim Phillips <kim.phillips@freescale.com>
Thanks,
Kim
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: remove section changes from _GLOBAL() and friends
From: Stephen Rothwell @ 2013-04-15 16:17 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Alan Modra, ppc-dev
In-Reply-To: <20130415233040.ca38e79ce08c519554baa865@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1092 bytes --]
Hi Michael,
On Mon, 15 Apr 2013 23:30:40 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 15 Apr 2013 22:00:17 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > On Thu, Nov 29, 2012 at 10:55:25AM +1100, Stephen Rothwell wrote:
> > > These sometimes produce unexpected results and make it hard to put the
> > > start up code (for 64 bit) into the .head.text section.
> >
> > ...
> >
> > > diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> > > index 6f62a73..4ec5625 100644
> > > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > > @@ -776,6 +776,8 @@ tlb_write_entry:
> > > mfspr r10, SPRN_SPRG_RSCRATCH0
> > > rfi /* Force context change */
> > >
> > > + ,text
> > > +
> >
> > I'm assuming this should be .text ?
>
> Indeed. Oops :-)
BTW, those patches are almost certainly stale by now and would need to be
redone before be included on the kernel proper.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] iommu: Move swap_pci_ref function to pci.h.
From: Bjorn Helgaas @ 2013-04-15 15:34 UTC (permalink / raw)
To: Joerg Roedel
Cc: stuart.yoder, linux-kernel@vger.kernel.org,
open list:INTEL IOMMU (VT-d), scottwood, Varun Sethi,
linuxppc-dev
In-Reply-To: <20130415145834.GR6858@8bytes.org>
On Mon, Apr 15, 2013 at 8:58 AM, Joerg Roedel <joro@8bytes.org> wrote:
> On Mon, Apr 15, 2013 at 12:42:00AM +0530, Varun Sethi wrote:
>> swap_pci_ref function is used by the IOMMU API code for swapping pci device
>> pointers, while determining the iommu group for the device.
>> Currently this function was being implemented for different IOMMU drivers.
>> This patch moves the function to pci.h so that the implementation can be
>> shared across various IOMMU drivers.
>
> The function is only used in IOMMU code, so I think its fine to keep it
> there (unless Bjorn disagrees and wants it in PCI code).
I agree; I don't think there's much benefit in putting something under
#ifdef CONFIG_IOMMU_API into pci.h. Maybe there is or could be a
shared iommu header file?
Bjorn
^ permalink raw reply
* Re: [PATCH 1/3] iommu: Move swap_pci_ref function to pci.h.
From: Joerg Roedel @ 2013-04-15 14:58 UTC (permalink / raw)
To: Varun Sethi
Cc: linux-kernel, stuart.yoder, bhelgaas, iommu, scottwood,
linuxppc-dev
In-Reply-To: <1365966722-1804-1-git-send-email-Varun.Sethi@freescale.com>
On Mon, Apr 15, 2013 at 12:42:00AM +0530, Varun Sethi wrote:
> swap_pci_ref function is used by the IOMMU API code for swapping pci device
> pointers, while determining the iommu group for the device.
> Currently this function was being implemented for different IOMMU drivers.
> This patch moves the function to pci.h so that the implementation can be
> shared across various IOMMU drivers.
The function is only used in IOMMU code, so I think its fine to keep it
there (unless Bjorn disagrees and wants it in PCI code).
Joerg
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: remove section changes from _GLOBAL() and friends
From: Stephen Rothwell @ 2013-04-15 13:30 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Alan Modra, ppc-dev
In-Reply-To: <20130415120016.GB12701@concordia>
[-- Attachment #1: Type: text/plain, Size: 836 bytes --]
Hi Michael,
On Mon, 15 Apr 2013 22:00:17 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> On Thu, Nov 29, 2012 at 10:55:25AM +1100, Stephen Rothwell wrote:
> > These sometimes produce unexpected results and make it hard to put the
> > start up code (for 64 bit) into the .head.text section.
>
> ...
>
> > diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> > index 6f62a73..4ec5625 100644
> > --- a/arch/powerpc/kernel/head_fsl_booke.S
> > +++ b/arch/powerpc/kernel/head_fsl_booke.S
> > @@ -776,6 +776,8 @@ tlb_write_entry:
> > mfspr r10, SPRN_SPRG_RSCRATCH0
> > rfi /* Force context change */
> >
> > + ,text
> > +
>
> I'm assuming this should be .text ?
Indeed. Oops :-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] powerpc: remove section changes from _GLOBAL() and friends
From: Michael Ellerman @ 2013-04-15 12:00 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: Alan Modra, ppc-dev
In-Reply-To: <20121129105525.0e47b3b3e51aebe7ded3b7b6@canb.auug.org.au>
On Thu, Nov 29, 2012 at 10:55:25AM +1100, Stephen Rothwell wrote:
> These sometimes produce unexpected results and make it hard to put the
> start up code (for 64 bit) into the .head.text section.
...
> diff --git a/arch/powerpc/kernel/head_fsl_booke.S b/arch/powerpc/kernel/head_fsl_booke.S
> index 6f62a73..4ec5625 100644
> --- a/arch/powerpc/kernel/head_fsl_booke.S
> +++ b/arch/powerpc/kernel/head_fsl_booke.S
> @@ -776,6 +776,8 @@ tlb_write_entry:
> mfspr r10, SPRN_SPRG_RSCRATCH0
> rfi /* Force context change */
>
> + ,text
> +
I'm assuming this should be .text ?
cheers
^ permalink raw reply
* Re: [PATCHv3 1/2] ppc64: perform proper max_bus_speed detection
From: Michael Ellerman @ 2013-04-15 11:42 UTC (permalink / raw)
To: Lucas Kannebley Tavares
Cc: David Airlie, Brian King, dri-devel, Kleber Sacilotto de Souza,
Alex Deucher, Jerome Glisse, Thadeu Lima de Souza Cascardo,
Bjorn Helgaas, linuxppc-dev
In-Reply-To: <1365685994-32603-2-git-send-email-lucaskt@linux.vnet.ibm.com>
On Thu, Apr 11, 2013 at 10:13:13AM -0300, Lucas Kannebley Tavares wrote:
> On pseries machines the detection for max_bus_speed should be done
> through an OpenFirmware property. This patch adds a function to perform this
> detection and a hook to perform dynamic adding of the function only for
> pseries.
This fails to build for me on ppc64_defconfig, with:
arch/powerpc/include/asm/machdep.h:111:5: error: 'struct pci_host_bridge' declared inside parameter list [-Werror]
Presumably you tested it using some other defconfig?
cheers
^ permalink raw reply
* Re: [RFC PATCH v2 3/4] powerpc: Don't bolt the hpte in kernel_map_linear_page()
From: Benjamin Herrenschmidt @ 2013-04-15 11:27 UTC (permalink / raw)
To: Li Zhong; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1366013711.12424.33.camel@ThinkPad-T5421.cn.ibm.com>
On Mon, 2013-04-15 at 16:15 +0800, Li Zhong wrote:
> So the code is implemented in ppc_md.hpte_remove(), may be called by
> __hash_huge_page(), and asm code htab_call_hpte_remove?
>
> > This is why the linear mapping (and the vmemmap) must be bolted.
>
> If not, it would result the infinite recursion like above?
Potentially, we don't expect to fault linear mapping or vmemmap entries
on demand. We aren't equipped to do it and we occasionally have code
path that access the linear mapping and cannot afford to have SRR0 and
SRR1 clobbered by a page fault.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] powerpc/perf: Power8 PMU support
From: Michael Ellerman @ 2013-04-15 10:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linux-kernel, acme, linuxppc-dev, Paul Mackerras, Anton Blanchard,
sukadev
In-Reply-To: <1366011086.24994.33.camel@pasglop>
On Mon, Apr 15, 2013 at 09:31:26AM +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-15 at 14:17 +1000, Michael Ellerman wrote:
> > This patch adds preliminary support for the power8 PMU to perf.
>
> Might be worthwhile to have a small blurb explaining roughly what you
> mean by "preliminary" :-)
True.
There's no alternative handling, and no cache events. I need to work
with the HW folks on both of those.
Also missing is EBB support. I will hopefully post that in the next few
days.
cheers
^ permalink raw reply
* Re: [RFC PATCH v2 4/4] powerpc: Try to insert the hptes repeatedly in kernel_map_linear_page()
From: Li Zhong @ 2013-04-15 8:21 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus
In-Reply-To: <20130415063658.GF21147@concordia>
On Mon, 2013-04-15 at 16:36 +1000, Michael Ellerman wrote:
> On Fri, Apr 12, 2013 at 10:17:00AM +0800, Li Zhong wrote:
> > This patch tries to fix following issue when CONFIG_DEBUG_PAGEALLOC
> > is enabled:
>
> Please include a better changelog.
OK, I'll use the following as a template, thank you for the suggestion.
>
> This patch does fix (I hope?) the following oops, caused by xxx. Reproducible
> by doing yyy.
>
> cheers
>
> >
> > [ 543.075675] ------------[ cut here ]------------
> > [ 543.075701] kernel BUG at arch/powerpc/mm/hash_utils_64.c:1239!
> > [ 543.075714] Oops: Exception in kernel mode, sig: 5 [#1]
> > [ 543.075722] PREEMPT SMP NR_CPUS=16 DEBUG_PAGEALLOC NUMA pSeries
> > [ 543.075741] Modules linked in: binfmt_misc ehea
> > [ 543.075759] NIP: c000000000036eb0 LR: c000000000036ea4 CTR: c00000000005a594
> > [ 543.075771] REGS: c0000000a90832c0 TRAP: 0700 Not tainted (3.8.0-next-20130222)
> > [ 543.075781] MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 22224482 XER: 00000000
> > [ 543.075816] SOFTE: 0
> > [ 543.075823] CFAR: c00000000004c200
> > [ 543.075830] TASK = c0000000e506b750[23934] 'cc1' THREAD: c0000000a9080000 CPU: 1
> > GPR00: 0000000000000001 c0000000a9083540 c000000000c600a8 ffffffffffffffff
> > GPR04: 0000000000000050 fffffffffffffffa c0000000a90834e0 00000000004ff594
> > GPR08: 0000000000000001 0000000000000000 000000009592d4d8 c000000000c86854
> > GPR12: 0000000000000002 c000000006ead300 0000000000a51000 0000000000000001
> > GPR16: f000000003354380 ffffffffffffffff ffffffffffffff80 0000000000000000
> > GPR20: 0000000000000001 c000000000c600a8 0000000000000001 0000000000000001
> > GPR24: 0000000003354380 c000000000000000 0000000000000000 c000000000b65950
> > GPR28: 0000002000000000 00000000000cd50e 0000000000bf50d9 c000000000c7c230
> > [ 543.076005] NIP [c000000000036eb0] .kernel_map_pages+0x1e0/0x3f8
> > [ 543.076016] LR [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8
> > [ 543.076025] Call Trace:
> > [ 543.076033] [c0000000a9083540] [c000000000036ea4] .kernel_map_pages+0x1d4/0x3f8 (unreliable)
> > [ 543.076053] [c0000000a9083640] [c000000000167638] .get_page_from_freelist+0x6cc/0x8dc
> > [ 543.076067] [c0000000a9083800] [c000000000167a48] .__alloc_pages_nodemask+0x200/0x96c
> > [ 543.076082] [c0000000a90839c0] [c0000000001ade44] .alloc_pages_vma+0x160/0x1e4
> > [ 543.076098] [c0000000a9083a80] [c00000000018ce04] .handle_pte_fault+0x1b0/0x7e8
> > [ 543.076113] [c0000000a9083b50] [c00000000018d5a8] .handle_mm_fault+0x16c/0x1a0
> > [ 543.076129] [c0000000a9083c00] [c0000000007bf1dc] .do_page_fault+0x4d0/0x7a4
> > [ 543.076144] [c0000000a9083e30] [c0000000000090e8] handle_page_fault+0x10/0x30
> > [ 543.076155] Instruction dump:
> > [ 543.076163] 7c630038 78631d88 e80a0000 f8410028 7c0903a6 e91f01de e96a0010 e84a0008
> > [ 543.076192] 4e800421 e8410028 7c7107b4 7a200fe0 <0b000000> 7f63db78 48785781 60000000
> > [ 543.076224] ---[ end trace bd5807e8d6ae186b ]---
> >
> > Signed-off-by: Li Zhong <zhong@linux.vnet.ibm.com>
> > ---
> > arch/powerpc/mm/hash_utils_64.c | 10 ++++++----
> > 1 file changed, 6 insertions(+), 4 deletions(-)
> >
> > diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> > index a7f54f0..4b449a0 100644
> > --- a/arch/powerpc/mm/hash_utils_64.c
> > +++ b/arch/powerpc/mm/hash_utils_64.c
> > @@ -1272,7 +1272,7 @@ static void kernel_map_linear_page(unsigned long vaddr, unsigned long lmi)
> > unsigned long vsid = get_kernel_vsid(vaddr, mmu_kernel_ssize);
> > unsigned long vpn = hpt_vpn(vaddr, vsid, mmu_kernel_ssize);
> > unsigned long mode = htab_convert_pte_flags(PAGE_KERNEL);
> > - int ret;
> > + long ret;
> >
> > hash = hpt_hash(vpn, PAGE_SHIFT, mmu_kernel_ssize);
> > hpteg = ((hash & htab_hash_mask) * HPTES_PER_GROUP);
> > @@ -1280,9 +1280,11 @@ static void kernel_map_linear_page(unsigned long vaddr, unsigned long lmi)
> > /* Don't create HPTE entries for bad address */
> > if (!vsid)
> > return;
> > - ret = ppc_md.hpte_insert(hpteg, vpn, __pa(vaddr),
> > - mode, 0,
> > - mmu_linear_psize, mmu_kernel_ssize);
> > +
> > + ret = hpte_insert_repeating(hash, vpn, __pa(vaddr),
> > + mode, mmu_linear_psize,
> > + mmu_kernel_ssize);
> > +
> > BUG_ON (ret < 0);
> > spin_lock(&linear_map_hash_lock);
> > BUG_ON(linear_map_hash_slots[lmi] & 0x80);
> > --
> > 1.7.9.5
> >
>
^ permalink raw reply
* Re: [RFC PATCH v2 1/4] powerpc: Move the setting of rflags out of loop in __hash_page_huge
From: Li Zhong @ 2013-04-15 8:17 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, paulus
In-Reply-To: <20130415063258.GE21147@concordia>
On Mon, 2013-04-15 at 16:32 +1000, Michael Ellerman wrote:
> On Fri, Apr 12, 2013 at 10:16:57AM +0800, Li Zhong wrote:
> > It seems that rflags don't get changed in the repeating loop, so move
> > it out of the loop.
> You've also changed the way new_pte is handled on repeat, but I think
> that's OK too.
OK, I'll add it in the description :)
Thanks, Zhong
> cheers
>
> > diff --git a/arch/powerpc/mm/hugetlbpage-hash64.c b/arch/powerpc/mm/hugetlbpage-hash64.c
> > index cecad34..edb4129 100644
> > --- a/arch/powerpc/mm/hugetlbpage-hash64.c
> > +++ b/arch/powerpc/mm/hugetlbpage-hash64.c
> > @@ -87,10 +87,6 @@ int __hash_page_huge(unsigned long ea, unsigned long access, unsigned long vsid,
> >
> > pa = pte_pfn(__pte(old_pte)) << PAGE_SHIFT;
> >
> > -repeat:
> > - hpte_group = ((hash & htab_hash_mask) *
> > - HPTES_PER_GROUP) & ~0x7UL;
> > -
> > /* clear HPTE slot informations in new PTE */
> > #ifdef CONFIG_PPC_64K_PAGES
> > new_pte = (new_pte & ~_PAGE_HPTEFLAGS) | _PAGE_HPTE_SUB0;
>
> ie. here new_pte was updated on repeat, but now it's not.
>
> > @@ -101,6 +97,10 @@ repeat:
> > rflags |= (new_pte & (_PAGE_WRITETHRU | _PAGE_NO_CACHE |
> > _PAGE_COHERENT | _PAGE_GUARDED));
> >
> > +repeat:
> > + hpte_group = ((hash & htab_hash_mask) *
> > + HPTES_PER_GROUP) & ~0x7UL;
> > +
> > /* Insert into the hash table, primary slot */
> > slot = ppc_md.hpte_insert(hpte_group, vpn, pa, rflags, 0,
> > mmu_psize, ssize);
>
^ permalink raw reply
* Re: [RFC PATCH v2 3/4] powerpc: Don't bolt the hpte in kernel_map_linear_page()
From: Li Zhong @ 2013-04-15 8:15 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1366008995.24994.25.camel@pasglop>
On Mon, 2013-04-15 at 08:56 +0200, Benjamin Herrenschmidt wrote:
> On Mon, 2013-04-15 at 13:50 +1000, Paul Mackerras wrote:
> > On Fri, Apr 12, 2013 at 10:16:59AM +0800, Li Zhong wrote:
> > > It seems that in kernel_unmap_linear_page(), it only checks whether there
> > > is a map in the linear_map_hash_slots array, so seems we don't need bolt
> > > the hpte.
> >
Hi Paul, Ben
Thank you both for the comments and detailed information. I'll keep it
bolted in the next version. If you have time, please help to check
whether my understanding below is correct.
Thanks, Zhong
> > I don't exactly understand your rationale here, but I don't think it's
> > safe not to have linear mapping pages bolted. Basically, if a page
> > will be used in the process of calling hash_page to demand-fault an
> > HPTE into the hash table, then that page needs to be bolted, otherwise
> > we can get an infinite recursion of HPT misses.
So the infinite recursion happens like below?
fault for PAGE A
hash_page for PAGE A
some page B needed by hash_page processing removed by others,
before inserting the HPTE
fault for PAGE B
hash_page for PAGE B and recursion for ever
> That includes all
> > kernel stack pages, among other things, so I think we need to leave
> > the HPTE_V_BOLTED in there.
>
> I suspect Li's confusion comes from the fact that he doesn't realizes
> that we might evict random hash slots. If the linear mapping hash
> entries could only be thrown out via kernel_unmap_linear_page() then his
> comment would make sense. However this isn't the case.
>
> Li: When faulting something in, if both the primary and secondary
> buckets are full, we "somewhat randomly" evict the content of a slot and
> replace it. However we only do that on non-bolted slots.
So the code is implemented in ppc_md.hpte_remove(), may be called by
__hash_huge_page(), and asm code htab_call_hpte_remove?
> This is why the linear mapping (and the vmemmap) must be bolted.
If not, it would result the infinite recursion like above?
> Cheers,
> Ben.
>
>
^ permalink raw reply
* Re: [PATCH 5/8] Read rtas partition via pstore
From: Michael Ellerman @ 2013-04-15 8:01 UTC (permalink / raw)
To: Aruna Balakrishnaiah
Cc: jkenisto, mahesh, linux-kernel, linuxppc-dev, paulus, anton
In-Reply-To: <20130410072327.20150.42189.stgit@aruna-ThinkPad-T420>
On Wed, Apr 10, 2013 at 12:53:27PM +0530, Aruna Balakrishnaiah wrote:
> This patch exploits pstore infrastructure to read the details
> from NVRAM's rtas partition.
Does that mean it's exposed in the pstore filesystem?
> Signed-off-by: Aruna Balakrishnaiah <aruna@linux.vnet.ibm.com>
> Reviewed-by: Jim Keniston <jkenisto@us.ibm.com>
> ---
> arch/powerpc/platforms/pseries/nvram.c | 33 +++++++++++++++++++++++++-------
> fs/pstore/inode.c | 3 +++
> include/linux/pstore.h | 2 ++
> 3 files changed, 31 insertions(+), 7 deletions(-)
>
> diff --git a/arch/powerpc/platforms/pseries/nvram.c b/arch/powerpc/platforms/pseries/nvram.c
> index 82d32a2..d420b1d 100644
> --- a/arch/powerpc/platforms/pseries/nvram.c
> +++ b/arch/powerpc/platforms/pseries/nvram.c
> @@ -144,9 +144,11 @@ static size_t oops_data_sz;
> #ifdef CONFIG_PSTORE
> static enum pstore_type_id nvram_type_ids[] = {
> PSTORE_TYPE_DMESG,
> + PSTORE_TYPE_RTAS,
> -1
> };
> static int read_type;
> +static unsigned long last_rtas_event;
> #endif
> /* Compression parameters */
> #define COMPR_LEVEL 6
> @@ -315,8 +317,13 @@ int nvram_write_error_log(char * buff, int length,
> {
> int rc = nvram_write_os_partition(&rtas_log_partition, buff, length,
> err_type, error_log_cnt);
> - if (!rc)
> + if (!rc) {
> last_unread_rtas_event = get_seconds();
> +#ifdef CONFIG_PSTORE
> + last_rtas_event = get_seconds();
> +#endif
> + }
> +
> return rc;
> }
>
> @@ -745,7 +752,7 @@ static int nvram_pstore_write(enum pstore_type_id type,
> }
>
> /*
> - * Reads the oops/panic report.
> + * Reads the oops/panic report and ibm,rtas-log partition.
> * Returns the length of the data we read from each partition.
> * Returns 0 if we've been called before.
> */
> @@ -765,6 +772,12 @@ static ssize_t nvram_pstore_read(u64 *id, enum pstore_type_id *type,
> part = &oops_log_partition;
> *type = PSTORE_TYPE_DMESG;
> break;
> + case PSTORE_TYPE_RTAS:
> + part = &rtas_log_partition;
> + *type = PSTORE_TYPE_RTAS;
> + time->tv_sec = last_rtas_event;
> + time->tv_nsec = 0;
> + break;
> default:
> return 0;
> }
> @@ -781,11 +794,17 @@ static ssize_t nvram_pstore_read(u64 *id, enum pstore_type_id *type,
>
> *count = 0;
> *id = id_no;
> - oops_hdr = (struct oops_log_info *)buff;
> - *buf = buff + sizeof(*oops_hdr);
> - time->tv_sec = oops_hdr->timestamp;
> - time->tv_nsec = 0;
> - return oops_hdr->report_length;
> +
> + if (nvram_type_ids[read_type] == PSTORE_TYPE_DMESG) {
> + oops_hdr = (struct oops_log_info *)buff;
> + *buf = buff + sizeof(*oops_hdr);
> + time->tv_sec = oops_hdr->timestamp;
> + time->tv_nsec = 0;
> + return oops_hdr->report_length;
> + }
> +
> + *buf = buff;
> + return part->size;
> }
> #else
> static int nvram_pstore_open(struct pstore_info *psi)
> diff --git a/fs/pstore/inode.c b/fs/pstore/inode.c
> index e4bcb2c..59b1454 100644
> --- a/fs/pstore/inode.c
> +++ b/fs/pstore/inode.c
> @@ -324,6 +324,9 @@ int pstore_mkfile(enum pstore_type_id type, char *psname, u64 id, int count,
> case PSTORE_TYPE_MCE:
> sprintf(name, "mce-%s-%lld", psname, id);
> break;
> + case PSTORE_TYPE_RTAS:
> + sprintf(name, "rtas-%s-%lld", psname, id);
> + break;
> case PSTORE_TYPE_UNKNOWN:
> sprintf(name, "unknown-%s-%lld", psname, id);
> break;
> diff --git a/include/linux/pstore.h b/include/linux/pstore.h
> index 75d0176..4eb94c9 100644
> --- a/include/linux/pstore.h
> +++ b/include/linux/pstore.h
> @@ -35,6 +35,8 @@ enum pstore_type_id {
> PSTORE_TYPE_MCE = 1,
> PSTORE_TYPE_CONSOLE = 2,
> PSTORE_TYPE_FTRACE = 3,
> + /* PPC64 partition types */
> + PSTORE_TYPE_RTAS = 10,
> PSTORE_TYPE_UNKNOWN = 255
I think you should probably just continue at 4, and call it
PSTORE_TYPE_PPC_RTAS. But you must get an ACK from the pstore
maintainers for this and the previous hunk, and I don't see them on CC.
cheers
^ permalink raw reply
* Re: [PATCH 2/8] Add version and timestamp to oops header
From: aruna @ 2013-04-15 7:51 UTC (permalink / raw)
To: Michael Ellerman
Cc: jkenisto, mahesh, linux-kernel, linuxppc-dev, paulus, anton
In-Reply-To: <20130415073138.GB30156@concordia>
On Monday 15 April 2013 01:01 PM, Michael Ellerman wrote:
> On Wed, Apr 10, 2013 at 12:51:12PM +0530, Aruna Balakrishnaiah wrote:
>> Introduce version and timestamp information in the oops header.
>> oops_log_info (oops header) holds version (to distinguish between old
>> and new format oops header), length of the oops text
>> (compressed or uncompressed) and timestamp.
> This needs a much more detailed explanation.
>
> I think what you're doing is you're overlaying the new information so
> that the version field in oops_log_info sits in the same location as the
> length field in the old format. And then you're defining the version to
> be a value that is an illegal length.
Thats right.
> So existing tools will refuse to dump new style partitions,
> because they'll think the length is too large. You've tested that?
Yeah, I have tested that.
>
> Updated tools will know about both formats, so will be able to handle
> either old or new style partitions.
>
> Is that correct?
Yeah, thats correct.
>
> And we're adding the timestamp just because we can and it'd be nice to
> have?
Thats right. And also, the main reason behind adding timestamp is
it will be used when we create a pstore file for oops messages.
The pstore file's timestamp will reflect the timestamp in the oops-header
added during the crash.
> cheers
>
^ 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