* Re: [PATCH 3/4 v5] video, sm501: add OF binding to support SM501
From: Heiko Schocher @ 2011-03-22 8:25 UTC (permalink / raw)
To: Paul Mundt
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, Randy Dunlap, linuxppc-dev,
Wolfgang Denk
In-Reply-To: <20110322082047.GG25925@linux-sh.org>
Hello Paul,
Paul Mundt wrote:
> On Thu, Mar 17, 2011 at 07:12:56AM +0100, Heiko Schocher wrote:
>> Paul Mundt schrieb:
>>> On Tue, Mar 15, 2011 at 08:26:40AM +0100, Heiko Schocher wrote:
>>>>> 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style problems and is ready for submission.
>>>>>
>>>>> Documentation/powerpc/dts-bindings/sm501.txt | 34 +++++++++++++++++++++
>>>>> drivers/mfd/sm501.c | 9 +++++-
>>>>> drivers/video/sm501fb.c | 42 ++++++++++++++++++++++++--
>>>>> 3 files changed, 81 insertions(+), 4 deletions(-)
>>>>> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
>>>> This patchset is pending know for a while. I got Acked by from
>>>>
>>>> Samuel Ortiz for the mfd part, see here:
>>>>
>>>> http://www.spinics.net/lists/linux-fbdev/msg02550.html
>>>> http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html
>>>>
>>>> and for the DTS part from Benjamin Herrenschmidt:
>>>>
>>>> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html
>>>>
>>>> Are there some more issues?
>>>>
>>> Not that I remember off the top of my head, but I think they've been lost
>>> in my backlog. Could you re-send the current series with the appropriate
>>> acked-bys? If there's nothing else obvious outstanding I'll roll them in.
>> Ok, I resend them (I also rebase them to current tree, ok?)
>>
> Ok, I've dug them up on l-k in the meantime and applied 1-3. 4/4 doesn't
> apply due to a missing dts file, but I assume you're aware of that and
> will take care of it separately. Let me know if I've overlooked anything,
> and sorry for the delay!
No problem!
Just working on this patchset (rebase and check if it boots/works) ... will
post the update (with all patches again) in some minutes, so please wait
for it.
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
^ permalink raw reply
* Re: [PATCH 3/4 v5] video, sm501: add OF binding to support SM501
From: Paul Mundt @ 2011-03-22 8:20 UTC (permalink / raw)
To: Heiko Schocher
Cc: linux-fbdev, devicetree-discuss, Samuel Ortiz, Vincent Sanders,
linux-kernel, Ben Dooks, Randy Dunlap, linuxppc-dev,
Wolfgang Denk
In-Reply-To: <4D81A668.8060500@denx.de>
On Thu, Mar 17, 2011 at 07:12:56AM +0100, Heiko Schocher wrote:
> Paul Mundt schrieb:
> > On Tue, Mar 15, 2011 at 08:26:40AM +0100, Heiko Schocher wrote:
> >>> 0003-video-sm501-add-OF-binding-to-support-SM501.patch has no obvious style problems and is ready for submission.
> >>>
> >>> Documentation/powerpc/dts-bindings/sm501.txt | 34 +++++++++++++++++++++
> >>> drivers/mfd/sm501.c | 9 +++++-
> >>> drivers/video/sm501fb.c | 42 ++++++++++++++++++++++++--
> >>> 3 files changed, 81 insertions(+), 4 deletions(-)
> >>> create mode 100644 Documentation/powerpc/dts-bindings/sm501.txt
> >> This patchset is pending know for a while. I got Acked by from
> >>
> >> Samuel Ortiz for the mfd part, see here:
> >>
> >> http://www.spinics.net/lists/linux-fbdev/msg02550.html
> >> http://linux.derkeiler.com/Mailing-Lists/Kernel/2011-01/msg11798.html
> >>
> >> and for the DTS part from Benjamin Herrenschmidt:
> >>
> >> http://lists.ozlabs.org/pipermail/linuxppc-dev/2011-February/088279.html
> >>
> >> Are there some more issues?
> >>
> > Not that I remember off the top of my head, but I think they've been lost
> > in my backlog. Could you re-send the current series with the appropriate
> > acked-bys? If there's nothing else obvious outstanding I'll roll them in.
>
> Ok, I resend them (I also rebase them to current tree, ok?)
>
Ok, I've dug them up on l-k in the meantime and applied 1-3. 4/4 doesn't
apply due to a missing dts file, but I assume you're aware of that and
will take care of it separately. Let me know if I've overlooked anything,
and sorry for the delay!
^ permalink raw reply
* Query: PCIe range entry at pcie@0 in dts files
From: Kushwaha Prabhakar-B32579 @ 2011-03-22 4:18 UTC (permalink / raw)
To: linuxppc-dev@lists.ozlabs.org
Hi all,
I have query about usage of range field at pcie@0 under PCIe controller. P=
lease find snap shot from mpc8536_36.dts..
pci3: pcie@fffe0b000 {
compatible =3D "fsl,mpc8548-pcie";
device_type =3D "pci";
#interrupt-cells =3D <1>;
#size-cells =3D <2>;
#address-cells =3D <3>;
reg =3D <0xf 0xffe0b000 0 0x1000>;
bus-range =3D <0 0xff>;
ranges =3D <0x02000000 0 0xe0000000 0xc 0x20000000 0 0x20000000
0x01000000 0 0x00000000 0xf 0xffc30000 0 0x00010000>;
clock-frequency =3D <33333333>;
interrupt-parent =3D <&mpic>;
interrupts =3D <27 0x2>;
interrupt-map-mask =3D <0xf800 0 0 7>;
interrupt-map =3D <
/* IDSEL 0x0 */
0000 0 0 1 &mpic 8 1
0000 0 0 2 &mpic 9 1
0000 0 0 3 &mpic 10 1
0000 0 0 4 &mpic 11 1
>;
pcie@0 {
reg =3D <0 0 0 0 0>;
#size-cells =3D <2>;
#address-cells =3D <3>;
device_type =3D "pci";
ranges =3D <0x02000000 0 0xe0000000 --> child/port start address
0x02000000 0 0xe0000000 --> Parent bus address
0 0x20000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00100000>;
};
};
Question:
A) is ranges filed of pcie@0 really required?
I just went through the code and found scan_OF_for_pci_dev() called from =
pci_busdev_to_OF_node() touches pcie@0 node. But, It does not even uses ran=
ge filed.=20
static struct device_node *scan_OF_for_pci_dev(struct device_node *parent,=
unsigned int devfn) {
---
---
for_each_child_of_node(parent, np) {
reg =3D of_get_property(np, "reg", &psize);=20
=20
---
---
if (!strcmp(np->name, "multifunc-device")) {=20
=20
}
I also checked "Power_ePAPR_APPROVED_v1.0.pdf". It never say range filed=
required for child bus.
B) if range field of pcie@0 required. why does child/port start address sam=
e as Parent bus address? Range property provides mapping of port address t=
o parent address space.
So the value should be 0x00000000. Means port's address starting from 0x000=
00000 to size 0x20000000 is mapped parent's 0xe0000000.
ranges =3D <0x02000000 0 0x00000000 --> Child/port's start address
0x02000000 0 0xe0000000 --> Parent bus address
0 0x20000000
0x01000000 0 0x00000000
0x01000000 0 0x00000000
0 0x00100000>;
--Prabhakar
^ permalink raw reply
* Re: [PATCH v3 3/9] fsldma: use channel name in printk output
From: Dan Williams @ 2011-03-22 0:49 UTC (permalink / raw)
To: Ira W. Snyder; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1299174901-16762-4-git-send-email-iws@ovro.caltech.edu>
On Thu, Mar 3, 2011 at 9:54 AM, Ira W. Snyder <iws@ovro.caltech.edu> wrote:
> This makes debugging the driver much easier when multiple channels are
> running concurrently. In addition, you can see how much descriptor
> memory each channel has allocated via the dmapool API in sysfs.
>
> Signed-off-by: Ira W. Snyder <iws@ovro.caltech.edu>
> ---
> =A0drivers/dma/fsldma.c | =A0 69 +++++++++++++++++++++++++---------------=
---------
> =A0drivers/dma/fsldma.h | =A0 =A01 +
> =A02 files changed, 36 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/dma/fsldma.c b/drivers/dma/fsldma.c
> index 2e1af45..e535cd1 100644
> --- a/drivers/dma/fsldma.c
> +++ b/drivers/dma/fsldma.c
> @@ -37,7 +37,12 @@
>
> =A0#include "fsldma.h"
>
> -static const char msg_ld_oom[] =3D "No free memory for link descriptor\n=
";
> +#define chan_dbg(chan, fmt, arg...) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 dev_dbg(chan->dev, "%s: " fmt, chan->name, ##arg)
> +#define chan_err(chan, fmt, arg...) =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0\
> + =A0 =A0 =A0 dev_err(chan->dev, "%s: " fmt, chan->name, ##arg)
> +
I already have this applied, but if you want to send an incremental
cleanup patch you could achieve a similar effect without increasing
the size of fsldma_chan by using the class device that is created by
dma_async_device_register.
Something like:
#define to_chan_dev(chan) (&chan->common.dev->device)
#define chan_err(chan, fmt, arg...) \
dev_err(chan->dev, "%s: " fmt, dev_name(to_chan_dev(chan)), ##arg)
...where dev_name() returns something like "dma0chan0".
--
Dan
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-21 22:52 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: linuxppc-dev, Andrew Morton, Hugh Dickins, Peter Zijlstra
In-Reply-To: <4D873571.702@goop.org>
On Mon, 2011-03-21 at 11:24 +0000, Jeremy Fitzhardinge wrote:
>
> I'm very sorry about that, I didn't realize power was also using that
> interface. Unfortunately, the "no preemption" definition was an error,
> and had to be changed to match the pre-existing locking rules.
>
> Could you implement a similar "flush batched pte updates on context
> switch" as x86?
Well, we already do that for -rt & co.
However, we have another issue which is the reason we used those
lazy_mmu hooks to do our flushing.
Our PTEs eventually get faulted into a hash table which is what the real
MMU uses. We must never (ever) allow that hash table to contain a
duplicate entry for a given virtual address.
When we do a batch, we remove things from the linux PTE, and keep a
reference in our batch structure, and only update the hash table at the
end of the batch.
That means that we must not allow a hash fault to populate the hash with
a "new" PTE value prior to the old one having been flushed out (which is
possible if they different in protection attributes for example). For
that to happen, we must basically not allow a page fault to re-populate
a PTE invalidated by a batch before that batch has completed.
That translates to batches must only happen within a PTE lock section.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 1/2] powerpc: xics: fix numberspace mismatch from irq_desc conversion
From: Milton Miller @ 2011-03-21 21:38 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Lennert Buytenhek
In-Reply-To: <patches-for-39-rc1@mdm.bga.com>
commit 79f26c268ebad29bd75d078cfc09d3d82b30ccbd (powerpc:
platforms/pseries irq_data conversion) pushed irq_desc down into many
functions, dererencing the descriptor irq field as late as possible.
But it incorrectly passed a linix virtural irq number to RTAS,
resulting in the interrupt not being disabled and possibly
other bad things, such as another interrupt being disabled and/or
a checkstop.
In addition this missed the point of xics_mask_unknown_vec and
the seperation of xics_mask_real_irq from xics_mask_irq. When
xics_mask_unknown_vec is called it's because the hardware delivered an
irq source for which we have no linux irq allocated, and thefore we can
not have an irq_desc allocated.
Revert xics_mask_real_irq to its prior version, naming the argument
hwirq to highlight the difference.
Signed-off-by: Milton Miller <miltonm@bga.com>
--
Lennert can you please review the other patches for similar problems?
Any reference to irq_map[x].hwirq is in a different number domain.
I initially saw the problem pushing irq_desc through unknown_vec
found this due to my knowledge of the split (I added that function)
and only realized the wrong number space when preparing to test the fix.
In fact I tried without the patch and my firmware checkstops the machine
(hardware stops executing instructions)!
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 01fea46..5686db9 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -250,26 +250,26 @@ static unsigned int xics_startup(struct irq_data *d)
return 0;
}
-static void xics_mask_real_irq(struct irq_data *d)
+static void xics_mask_real_irq(unsigned int hwirq)
{
int call_status;
- if (d->irq == XICS_IPI)
+ if (hwirq == XICS_IPI)
return;
- call_status = rtas_call(ibm_int_off, 1, 1, NULL, d->irq);
+ call_status = rtas_call(ibm_int_off, 1, 1, NULL, hwirq);
if (call_status != 0) {
printk(KERN_ERR "%s: ibm_int_off irq=%u returned %d\n",
- __func__, d->irq, call_status);
+ __func__, hwirq, call_status);
return;
}
/* Have to set XIVE to 0xff to be able to remove a slot */
- call_status = rtas_call(ibm_set_xive, 3, 1, NULL, d->irq,
+ call_status = rtas_call(ibm_set_xive, 3, 1, NULL, hwirq,
default_server, 0xff);
if (call_status != 0) {
printk(KERN_ERR "%s: ibm_set_xive(0xff) irq=%u returned %d\n",
- __func__, d->irq, call_status);
+ __func__, hwirq, call_status);
return;
}
}
@@ -283,13 +283,13 @@ static void xics_mask_irq(struct irq_data *d)
irq = (unsigned int)irq_map[d->irq].hwirq;
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
return;
- xics_mask_real_irq(d);
+ xics_mask_real_irq(irq);
}
static void xics_mask_unknown_vec(unsigned int vec)
{
printk(KERN_ERR "Interrupt %u (real) is invalid, disabling it.\n", vec);
- xics_mask_real_irq(irq_get_irq_data(vec));
+ xics_mask_real_irq(vec);
}
static inline unsigned int xics_xirr_vector(unsigned int xirr)
^ permalink raw reply related
* Re: powerpc/pci: Make both ppc32 and ppc64 use sysdata for pci_controller
From: Grant Likely @ 2011-03-21 18:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Hugh Dickins, Linus Torvalds,
Linux Kernel Mailing List
In-Reply-To: <AANLkTikgG5JHimq5a2OsgsH+z+WsHO3MO6OU1q6_DzgH@mail.gmail.com>
[reposting part of private email exchange as penance for my sins...]
On Mon, Mar 21, 2011 at 12:22 PM, Grant Likely
<grant.likely@secretlab.ca> wrote:
> On Sun, Mar 20, 2011 at 4:52 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
>> Grant, what in hell makes you believe that this patch was ok to
>> merge upstream without even my Ack ?
>>
>> Yes, I told you I agree with the -principle-, but I also need to -test-
>> and review it properly which I haven't had a chance to do (and it does
>> break G5s at least it seems from the reports we are getting). In any
>> case this is clearly -NOT- within the boundaries of your devicetree
>> "tree" and should have gone through powerpc-next.
>
> Sorry Ben, I did not intend to merge that patch. =A0Quite simply I
> accidentally included it in my devicetree/next branch when I pushed
> out a bunch of other PCI related patches in February, and I overlooked
> that it was still in there when I sent Linus the pull request. =A0It was
> a complete failure on my part. =A0I apologize and submit myself for the
> required flogging.
A flogging schedule will be posted on the bulletin board in the lunch
room. Sorry for the trouble.
g.
^ permalink raw reply
* [PATCH 2/2] powerpc: xics: use hwirq for xics domain irq number
From: Milton Miller @ 2011-03-21 18:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <patches-for-39-rc1@mdm.bga.com>
To try to avoid future confusion, rename irq to hwirq when it refers
to a xics domain number instead of a linux irq number.
Signed-off-by: Milton Miller <miltonm@bga.com>
Index: next.git/arch/powerpc/platforms/pseries/xics.c
===================================================================
--- next.git.orig/arch/powerpc/platforms/pseries/xics.c 2011-03-19 23:21:21.775085058 -0500
+++ next.git/arch/powerpc/platforms/pseries/xics.c 2011-03-20 00:57:33.144560092 -0500
@@ -204,33 +204,33 @@ static int get_irq_server(unsigned int v
static void xics_unmask_irq(struct irq_data *d)
{
- unsigned int irq;
+ unsigned int hwirq;
int call_status;
int server;
pr_devel("xics: unmask virq %d\n", d->irq);
- irq = (unsigned int)irq_map[d->irq].hwirq;
- pr_devel(" -> map to hwirq 0x%x\n", irq);
- if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
+ hwirq = (unsigned int)irq_map[d->irq].hwirq;
+ pr_devel(" -> map to hwirq 0x%x\n", hwirq);
+ if (hwirq == XICS_IPI || hwirq == XICS_IRQ_SPURIOUS)
return;
server = get_irq_server(d->irq, d->affinity, 0);
- call_status = rtas_call(ibm_set_xive, 3, 1, NULL, irq, server,
+ call_status = rtas_call(ibm_set_xive, 3, 1, NULL, hwirq, server,
DEFAULT_PRIORITY);
if (call_status != 0) {
printk(KERN_ERR
"%s: ibm_set_xive irq %u server %x returned %d\n",
- __func__, irq, server, call_status);
+ __func__, hwirq, server, call_status);
return;
}
/* Now unmask the interrupt (often a no-op) */
- call_status = rtas_call(ibm_int_on, 1, 1, NULL, irq);
+ call_status = rtas_call(ibm_int_on, 1, 1, NULL, hwirq);
if (call_status != 0) {
printk(KERN_ERR "%s: ibm_int_on irq=%u returned %d\n",
- __func__, irq, call_status);
+ __func__, hwirq, call_status);
return;
}
}
@@ -276,14 +276,14 @@ static void xics_mask_real_irq(unsigned
static void xics_mask_irq(struct irq_data *d)
{
- unsigned int irq;
+ unsigned int hwirq;
pr_devel("xics: mask virq %d\n", d->irq);
- irq = (unsigned int)irq_map[d->irq].hwirq;
- if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
+ hwirq = (unsigned int)irq_map[d->irq].hwirq;
+ if (hwirq == XICS_IPI || hwirq == XICS_IRQ_SPURIOUS)
return;
- xics_mask_real_irq(irq);
+ xics_mask_real_irq(hwirq);
}
static void xics_mask_unknown_vec(unsigned int vec)
@@ -373,37 +373,37 @@ static unsigned char pop_cppr(void)
static void xics_eoi_direct(struct irq_data *d)
{
- unsigned int irq = (unsigned int)irq_map[d->irq].hwirq;
+ unsigned int hwirq = (unsigned int)irq_map[d->irq].hwirq;
iosync();
- direct_xirr_info_set((pop_cppr() << 24) | irq);
+ direct_xirr_info_set((pop_cppr() << 24) | hwirq);
}
static void xics_eoi_lpar(struct irq_data *d)
{
- unsigned int irq = (unsigned int)irq_map[d->irq].hwirq;
+ unsigned int hwirq = (unsigned int)irq_map[d->irq].hwirq;
iosync();
- lpar_xirr_info_set((pop_cppr() << 24) | irq);
+ lpar_xirr_info_set((pop_cppr() << 24) | hwirq);
}
static int
xics_set_affinity(struct irq_data *d, const struct cpumask *cpumask, bool force)
{
- unsigned int irq;
+ unsigned int hwirq;
int status;
int xics_status[2];
int irq_server;
- irq = (unsigned int)irq_map[d->irq].hwirq;
- if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
+ hwirq = (unsigned int)irq_map[d->irq].hwirq;
+ if (hwirq == XICS_IPI || hwirq == XICS_IRQ_SPURIOUS)
return -1;
- status = rtas_call(ibm_get_xive, 1, 3, xics_status, irq);
+ status = rtas_call(ibm_get_xive, 1, 3, xics_status, hwirq);
if (status) {
printk(KERN_ERR "%s: ibm,get-xive irq=%u returns %d\n",
- __func__, irq, status);
+ __func__, hwirq, status);
return -1;
}
@@ -418,11 +418,11 @@ xics_set_affinity(struct irq_data *d, co
}
status = rtas_call(ibm_set_xive, 3, 1, NULL,
- irq, irq_server, xics_status[1]);
+ hwirq, irq_server, xics_status[1]);
if (status) {
printk(KERN_ERR "%s: ibm,set-xive irq=%u returns %d\n",
- __func__, irq, status);
+ __func__, hwirq, status);
return -1;
}
@@ -874,7 +874,7 @@ void xics_kexec_teardown_cpu(int seconda
void xics_migrate_irqs_away(void)
{
int cpu = smp_processor_id(), hw_cpu = hard_smp_processor_id();
- unsigned int irq, virq;
+ int virq;
/* If we used to be the default server, move to the new "boot_cpuid" */
if (hw_cpu == default_server)
@@ -892,6 +892,7 @@ void xics_migrate_irqs_away(void)
for_each_irq(virq) {
struct irq_desc *desc;
struct irq_chip *chip;
+ unsigned int hwirq;
int xics_status[2];
int status;
unsigned long flags;
@@ -901,9 +902,9 @@ void xics_migrate_irqs_away(void)
continue;
if (irq_map[virq].host != xics_host)
continue;
- irq = (unsigned int)irq_map[virq].hwirq;
+ hwirq = (unsigned int)irq_map[virq].hwirq;
/* We need to get IPIs still. */
- if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
+ if (hwirq == XICS_IPI || hwirq == XICS_IRQ_SPURIOUS)
continue;
desc = irq_to_desc(virq);
@@ -918,10 +919,10 @@ void xics_migrate_irqs_away(void)
raw_spin_lock_irqsave(&desc->lock, flags);
- status = rtas_call(ibm_get_xive, 1, 3, xics_status, irq);
+ status = rtas_call(ibm_get_xive, 1, 3, xics_status, hwirq);
if (status) {
printk(KERN_ERR "%s: ibm,get-xive irq=%u returns %d\n",
- __func__, irq, status);
+ __func__, hwirq, status);
goto unlock;
}
^ permalink raw reply
* [PATCH] powerpc: pseries/smp: query-cpu-stopped-state support won't change
From: Milton Miller @ 2011-03-21 18:12 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <patches-for-39-rc1@mdm.bga.com>
If a given firmware doesn't have a token to support query-cpu-stopped-state,
its not likely to change during the lifetime of the kernel.
Only print this information once, not once per secondary thread.
While here, make the line wrap grep friendly.
Signed-off-by: Milton Miller <miltonm@bga.com>
Index: work.git/arch/powerpc/platforms/pseries/smp.c
===================================================================
--- work.git.orig/arch/powerpc/platforms/pseries/smp.c 2011-03-21 11:27:54.000000000 -0500
+++ work.git/arch/powerpc/platforms/pseries/smp.c 2011-03-21 11:29:51.000000000 -0500
@@ -64,8 +64,8 @@ int smp_query_cpu_stopped(unsigned int p
int qcss_tok = rtas_token("query-cpu-stopped-state");
if (qcss_tok == RTAS_UNKNOWN_SERVICE) {
- printk(KERN_INFO "Firmware doesn't support "
- "query-cpu-stopped-state\n");
+ printk_once(KERN_INFO
+ "Firmware doesn't support query-cpu-stopped-state\n");
return QCSS_HARDWARE_ERROR;
}
^ permalink raw reply
* [PATCH 0/3] xics mask_irq fix and other patches
From: Milton Miller @ 2011-03-21 18:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Hi Ben.
I've submitted the fix for the xics mask real irq I mentioned.
During testing I realized current code is passing rtas a linux irq,
which means no interrupt (at least those above NR_IRQs) is being disabled.
I also created a patch to rename irq to hwirq in xics to try to make
the distiction more clear. For your consideration, I don't care if you
don't merge it especially with the upcoming rewrite.
Also, I am sending a printk to printk_once patch that affects BML.
Thanks,
milton
MAIL FROM: <miltonm@bga.com>
RCPT TO: <miltonm@bga.com>
RCPT TO: <linuxppc-dev@lists.ozlabs.org>
RCPT TO: <buytenh@secretlab.ca>
DATA
From: Milton Miller <miltonm@bga.com>
Subject: [PATCH 1/2] powerpc: xics: fix numberspace mismatch from irq_desc conversion
To: linuxppc-dev@lists.ozlabs.org
Cc: Lennert Buytenhek <buytenh@secretlab.ca>
Message-id: <xics-mask-irq-desc-fix@mdm.bga.com>
In-Reply-To: <patches-for-39-rc1@mdm.bga.com>
References: <patches-for-39-rc1@mdm.bga.com>
commit 79f26c268ebad29bd75d078cfc09d3d82b30ccbd (powerpc:
platforms/pseries irq_data conversion) pushed irq_desc down into many
functions, dererencing the descriptor irq field as late as possible.
But it incorrectly passed a linix virtural irq number to RTAS,
resulting in the interrupt not being disabled and possibly
other bad things, such as another interrupt being disabled and/or
a checkstop.
In addition this missed the point of xics_mask_unknown_vec and
the seperation of xics_mask_real_irq from xics_mask_irq. When
xics_mask_unknown_vec is called it's because the hardware delivered an
irq source for which we have no linux irq allocated, and thefore we can
not have an irq_desc allocated.
Revert xics_mask_real_irq to its prior version, naming the argument
hwirq to highlight the difference.
Signed-off-by: Milton Miller <miltonm@bga.com>
--
Lennert can you please review the other patches for similar problems?
Any reference to irq_map[x].hwirq is in a different number domain.
I initially saw the problem pushing irq_desc through unknown_vec
found this due to my knowledge of the split (I added that function)
and only realized the wrong number space when preparing to test the fix.
In fact I tried without the patch and my firmware checkstops the machine
(hardware stops executing instructions)!
diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
index 01fea46..5686db9 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -250,26 +250,26 @@ static unsigned int xics_startup(struct irq_data *d)
return 0;
}
-static void xics_mask_real_irq(struct irq_data *d)
+static void xics_mask_real_irq(unsigned int hwirq)
{
int call_status;
- if (d->irq == XICS_IPI)
+ if (hwirq == XICS_IPI)
return;
- call_status = rtas_call(ibm_int_off, 1, 1, NULL, d->irq);
+ call_status = rtas_call(ibm_int_off, 1, 1, NULL, hwirq);
if (call_status != 0) {
printk(KERN_ERR "%s: ibm_int_off irq=%u returned %d\n",
- __func__, d->irq, call_status);
+ __func__, hwirq, call_status);
return;
}
/* Have to set XIVE to 0xff to be able to remove a slot */
- call_status = rtas_call(ibm_set_xive, 3, 1, NULL, d->irq,
+ call_status = rtas_call(ibm_set_xive, 3, 1, NULL, hwirq,
default_server, 0xff);
if (call_status != 0) {
printk(KERN_ERR "%s: ibm_set_xive(0xff) irq=%u returned %d\n",
- __func__, d->irq, call_status);
+ __func__, hwirq, call_status);
return;
}
}
@@ -283,13 +283,13 @@ static void xics_mask_irq(struct irq_data *d)
irq = (unsigned int)irq_map[d->irq].hwirq;
if (irq == XICS_IPI || irq == XICS_IRQ_SPURIOUS)
return;
- xics_mask_real_irq(d);
+ xics_mask_real_irq(irq);
}
static void xics_mask_unknown_vec(unsigned int vec)
{
printk(KERN_ERR "Interrupt %u (real) is invalid, disabling it.\n", vec);
- xics_mask_real_irq(irq_get_irq_data(vec));
+ xics_mask_real_irq(vec);
}
static inline unsigned int xics_xirr_vector(unsigned int xirr)
^ permalink raw reply related
* Re: mmotm threatens ppc preemption again
From: Jeremy Fitzhardinge @ 2011-03-21 11:24 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Andrew Morton, Hugh Dickins, Peter Zijlstra
In-Reply-To: <1300665188.2402.64.camel@pasglop>
On 03/20/2011 11:53 PM, Benjamin Herrenschmidt wrote:
> On Sat, 2011-03-19 at 21:11 -0700, Hugh Dickins wrote:
>> As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
>> patches in mmotm, which again assault PowerPC's expectations, and
>> cause lots of noise with CONFIG_PREEMPT=y CONFIG_PREEMPT_DEBUG=y.
>>
>> This time in vmalloc as well as vfree; and Peter's fix to the last
>> lot, which went into 2.6.38, doesn't protect against these ones.
>> Here's what I now see when I swapon and swapoff:
> Right. And we said from day one we had the HARD WIRED assumption that
> arch_enter/leave_lazy_mmu_mode() was ALWAYS going to be called within
> a PTE lock section, and we did get reassurance that it was going to
> remain so.
>
> So why is it ok for them to change those and break us like that ?
In general, the pagetable's locking rules are that all *usermode* pte
updates have to be done under a pte lock, but kernel mode ones do not;
they generally have some kind of per-subsystem ad-hoc locking where
needed, which may or may not be no-preempt.
Originally the enter/leave_lazy_mmu_mode did require preemption to be
disabled for the whole time, but that was incompatible with the above
locking rules, and resulted in preemption being disabled for long
periods when using lazy mode which wouldn't normally happen. This
raised a number of complaints.
To address this, I changed the x86 implementation to deal with
preemption in lazy mode by dropping out for lazy mode at context switch
time (and recording the fact that we were in lazy mode with a TIF flag
and re-entering on the next context switch).
> Seriously, this is going out of control. If we can't even rely on
> fundamental locking assumptions in the VM to remain reasonably stable
> or at least get some amount of -care- from who changes them as to
> whether they break others and work with us to fix them, wtf ?
>
> I don't know what the right way to fix that is. We have an absolute
> requirement that the batching we start within a lazy MMU section
> is complete and flushed before any other PTE in that section can be
> touched by anything else. Do we -at least- keep that guarantee ?
>
> If yes, then maybe preempt_disable/enable() around
> arch_enter/leave_lazy_mmu_mode() in apply_to_pte_range() would do...
>
> Or maybe I should just prevent any batching of init_mm :-(
I'm very sorry about that, I didn't realize power was also using that
interface. Unfortunately, the "no preemption" definition was an error,
and had to be changed to match the pre-existing locking rules.
Could you implement a similar "flush batched pte updates on context
switch" as x86?
J
^ permalink raw reply
* Re: [PATCH 1/2] kdump: Allow shrinking of kdump region to be overridden
From: WANG Cong @ 2011-03-21 3:10 UTC (permalink / raw)
To: linuxppc-dev; +Cc: linuxppc-dev, kexec, linux-kernel
In-Reply-To: <20110315165219.GA22509@in.ibm.com>
On Tue, 15 Mar 2011 22:22:19 +0530, Mahesh J Salgaonkar wrote:
> On Tue, Mar 15, 2011 at 03:52:38PM +0800, Américo Wang wrote:
>> On Tue, Mar 15, 2011 at 2:13 AM, Mahesh J Salgaonkar
>> <mahesh@linux.vnet.ibm.com> wrote:
>> >
>> > During free we do free all of them including RMO region. But since
>> > the rtas region is always on top of RMO, crashkernel memory overlaps
>> > rtas region and we endup freeing that even, which is causing the
>> > crash.
>> >
>> >
>> Okay, but with this patch applied, we will just ignore rtas region,
>> right?
> Correct.
>> Thus, when I echo 0 to free all the 128M crashkernel memory, the final
>> result will be 32M left, which means crash_size will still show 32M.
>> This looks odd.
>>
>> How about skipping the 32M as a whole? I mean once the region being
>> freed has overlap with this rtas region, skip the whole rtas region,
>> and let crash_size
>> show 0?
> The existing code from crash_shrink_memory() function reduces the crash
> size to 0 when echo'ed 0. I did test this patchset and verified that
> /sys/kernel/kexec_crash_size show 0 value.
Oh, ok.
Acked-by: WANG Cong <xiyou.wangcong@gmail.com>
Thanks.
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-21 2:22 UTC (permalink / raw)
To: Hugh Dickins
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
In-Reply-To: <alpine.LSU.2.00.1103201901340.7257@sister.anvils>
On Sun, 2011-03-20 at 19:20 -0700, Hugh Dickins wrote:
> > As long as the races to avoid are between map/unmap vs. access, yes, it
> > -should- be fine, and we used to not do demand faulting on kernel space
> > (but for how long ?). I'm wondering why we don't just stick a ptl in
> > there or is there a good reason why we can't ?
>
> We can - but we usually prefer to avoid unnecessary locking.
> An arch function which locks init_mm.page_table_lock on powerpc,
> but does nothing on others?
That still means gratuitous differences between how the normal and
kernel page tables are handled. Maybe that's not worth bothering ...
Cheers,
Ben.
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Hugh Dickins @ 2011-03-21 2:20 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev, Jeremy Fitzhardinge, Hugh Dickins, Andrew Morton,
Peter Zijlstra
In-Reply-To: <1300672207.2402.205.camel@pasglop>
On Mon, 21 Mar 2011, Benjamin Herrenschmidt wrote:
>
> As long as the races to avoid are between map/unmap vs. access, yes, it
> -should- be fine, and we used to not do demand faulting on kernel space
> (but for how long ?). I'm wondering why we don't just stick a ptl in
> there or is there a good reason why we can't ?
We can - but we usually prefer to avoid unnecessary locking.
An arch function which locks init_mm.page_table_lock on powerpc,
but does nothing on others?
Hugh
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-21 1:50 UTC (permalink / raw)
To: Hugh Dickins
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
In-Reply-To: <alpine.LSU.2.00.1103201814320.7035@sister.anvils>
On Sun, 2011-03-20 at 18:41 -0700, Hugh Dickins wrote:
> > I don't know what the right way to fix that is. We have an absolute
> > requirement that the batching we start within a lazy MMU section
> > is complete and flushed before any other PTE in that section can be
> > touched by anything else. Do we -at least- keep that guarantee ?
>
> I'm guessing it's a guarantee of the same kind as led me to skip
> page_table_lock on init_mm in 2.6.15: no locking to guarantee it,
> but it would have to be a kernel bug, in a driver or wherever,
> for us to be accessing such a section while it was in transit
> (short of speculative access prior to tlb flush).
As long as the races to avoid are between map/unmap vs. access, yes, it
-should- be fine, and we used to not do demand faulting on kernel space
(but for how long ?). I'm wondering why we don't just stick a ptl in
there or is there a good reason why we can't ?
> I don't see where you're doing batching on init_mm today:
> it looks as if Jeremy's patches, by using the same code as he has
> for user mms, are now enabling batching on init_mm, and you should :-)
>
> But I may be all wrong: it's between you and Jeremy,
> and until he defends them, his patches should not go forward.
We don't do it today (batching). Jeremy's patches have the side effect
of "enabling" it, which isn't wrong per-se ... but on our side relies on
some locking assumptions we are missing.
Cheers,
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2011-03-21 1:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
Hi Linus
Here's a fix for the regression introduced by
b5d937de0367d26f65b9af1aef5f2c34c1939be0 along with a bug fix from Mike
Wolf for a nasty BUG_ON() that shoudn't be there for some odd case of
threaded core dumps, and 3 patches from Meador Inge that I plain forgot
to include before.
Cheers,
Ben.
The following changes since commit a952baa034ae7c2e4a66932005cbc7ebbccfe28d:
Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input (2011-03-19 22:27:06 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
powerpc/pci: Fix crash in PCI code on ppc64 when matching device nodes
Meador Inge (3):
powerpc: Document the Open PIC device tree binding
powerpc: Make MPIC honor the "pic-no-reset" device tree property
powerpc: Factoring mpic cpu id fetching into a function
Mike Wolf (1):
powerpc/ptrace: Remove BUG_ON when full register set not available
Documentation/devicetree/bindings/open-pic.txt | 98 ++++++++++++++++++++++++
arch/powerpc/include/asm/mpic.h | 4 +
arch/powerpc/include/asm/ptrace.h | 2 +
arch/powerpc/kernel/pci_dn.c | 7 +-
arch/powerpc/kernel/ptrace.c | 15 +++-
arch/powerpc/sysdev/mpic.c | 85 +++++++++++++++-----
6 files changed, 184 insertions(+), 27 deletions(-)
create mode 100644 Documentation/devicetree/bindings/open-pic.txt
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Hugh Dickins @ 2011-03-21 1:41 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
In-Reply-To: <1300665188.2402.64.camel@pasglop>
On Mon, 21 Mar 2011, Benjamin Herrenschmidt wrote:
> On Sat, 2011-03-19 at 21:11 -0700, Hugh Dickins wrote:
> >
> > As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
> > patches in mmotm, which again assault PowerPC's expectations, and
> > cause lots of noise with CONFIG_PREEMPT=y CONFIG_PREEMPT_DEBUG=y.
> >
> > This time in vmalloc as well as vfree; and Peter's fix to the last
> > lot, which went into 2.6.38, doesn't protect against these ones.
> > Here's what I now see when I swapon and swapoff:
>
> Right. And we said from day one we had the HARD WIRED assumption that
> arch_enter/leave_lazy_mmu_mode() was ALWAYS going to be called within
> a PTE lock section, and we did get reassurance that it was going to
> remain so.
>
> So why is it ok for them to change those and break us like that ?
It's not ok. Sounds like Andrew should not forward
mm-remove-unused-token-argument-from-apply_to_page_range-callback.patch
mm-add-apply_to_page_range_batch.patch
ioremap-use-apply_to_page_range_batch-for-ioremap_page_range.patch
vmalloc-use-plain-pte_clear-for-unmaps.patch
vmalloc-use-apply_to_page_range_batch-for-vunmap_page_range.patch
vmalloc-use-apply_to_page_range_batch-for-vmap_page_range_noflush.patch
vmalloc-use-apply_to_page_range_batch-in-alloc_vm_area.patch
xen-mmu-use-apply_to_page_range_batch-in-xen_remap_domain_mfn_range.patch
xen-grant-table-use-apply_to_page_range_batch.patch
or some subset (the vmalloc-use-apply ones? and the ioremap one?)
of that set to Linus for 2.6.39. Your call.
>
> Seriously, this is going out of control. If we can't even rely on
> fundamental locking assumptions in the VM to remain reasonably stable
> or at least get some amount of -care- from who changes them as to
> whether they break others and work with us to fix them, wtf ?
I know next to nothing of arch_enter/leave_lazy_mmu_mode(),
and the same is probably true of most mm developers. The only
people who have it defined to anything interesting appear to be
powerpc and xen and lguest: so it would be a gentleman's agreement
between you and Jeremy and Rusty.
If Jeremy has changed the rules without your agreement, then you
can fight a duel at daybreak, or, since your daybreaks are at
different times, Jeremy's patches just shouldn't go forward yet.
>
> I don't know what the right way to fix that is. We have an absolute
> requirement that the batching we start within a lazy MMU section
> is complete and flushed before any other PTE in that section can be
> touched by anything else. Do we -at least- keep that guarantee ?
I'm guessing it's a guarantee of the same kind as led me to skip
page_table_lock on init_mm in 2.6.15: no locking to guarantee it,
but it would have to be a kernel bug, in a driver or wherever,
for us to be accessing such a section while it was in transit
(short of speculative access prior to tlb flush).
>
> If yes, then maybe preempt_disable/enable() around
> arch_enter/leave_lazy_mmu_mode() in apply_to_pte_range() would do...
>
> Or maybe I should just prevent any batching of init_mm :-(
I don't see where you're doing batching on init_mm today:
it looks as if Jeremy's patches, by using the same code as he has
for user mms, are now enabling batching on init_mm, and you should :-)
But I may be all wrong: it's between you and Jeremy,
and until he defends them, his patches should not go forward.
Hugh
^ permalink raw reply
* [PATCH] powerpc: Fix accounting of softirq time when idle
From: Anton Blanchard @ 2011-03-21 1:28 UTC (permalink / raw)
To: paulus, benh; +Cc: linuxppc-dev
commit cf9efce0ce31 (powerpc: Account time using timebase rather
than PURR) used in_irq() to detect if the time was spent in
interrupt processing. This only catches hardirq context so if we
are in softirq context and in the idle loop we end up accounting it
as idle time. If we instead use in_interrupt() we catch both softirq
and hardirq time.
The issue was found when running a network intensive workload. top
showed the following:
0.0%us, 1.1%sy, 0.0%ni, 85.7%id, 0.0%wa, 9.9%hi, 3.3%si, 0.0%st
85.7% idle. But this was wildly different to the perf events data.
To confirm the suspicion I ran something to keep the core busy:
# yes > /dev/null &
8.2%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 10.3%hi, 81.4%si, 0.0%st
We only got 8.2% of the CPU for the userspace task and softirq has
shot up to 81.4%.
With the patch below top shows the correct stats:
0.0%us, 0.0%sy, 0.0%ni, 5.3%id, 0.0%wa, 13.3%hi, 81.3%si, 0.0%st
Signed-off-by: Anton Blanchard <anton@samba.org>
Cc: stable@kernel.org
---
Index: linux-2.6/arch/powerpc/kernel/time.c
===================================================================
--- linux-2.6.orig/arch/powerpc/kernel/time.c 2011-03-21 12:05:12.056482258 +1100
+++ linux-2.6/arch/powerpc/kernel/time.c 2011-03-21 12:05:18.516721851 +1100
@@ -356,7 +356,7 @@ void account_system_vtime(struct task_st
}
get_paca()->user_time_scaled += user_scaled;
- if (in_irq() || idle_task(smp_processor_id()) != tsk) {
+ if (in_interrupt() || idle_task(smp_processor_id()) != tsk) {
account_system_time(tsk, 0, delta, sys_scaled);
if (stolen)
account_steal_time(stolen);
^ permalink raw reply
* Re: PowerMac7,3 dvd drive?
From: Benjamin Herrenschmidt @ 2011-03-21 0:24 UTC (permalink / raw)
To: kevin diggs; +Cc: linuxppc-dev
In-Reply-To: <AANLkTikRU9W61m7EcNONx9=Uinj-F7escWBCOTTdh==N@mail.gmail.com>
On Sun, 2011-03-20 at 18:52 -0500, kevin diggs wrote:
> I am seeing ... issues with the optical drive (hda) under 2.6.36. I
> can't mount disks:
>
> [root@PowerMacG5 ~]# mount -r /dev/hda /mnt/cdrom
> mount: /dev/hda already mounted or /mnt/cdrom busy
>
> The log has:
>
> [ 239.922268] hda: irq timeout: status=0xd0 { Busy }
> [ 239.922485] hda: possibly failed opcode: 0xa0
>
> eject hda will hang ... longer than my patience.
>
> At first I thought the drive was going south. But I don't see this (at
> least so far) on 2.6.28.
Do you see something similar if you use the new libata based driver
(macio-ata) instead of the old IDE driver ?
It does look like the drive itself is crashing tho. Maybe something the
IDE CDROM driver does upsets it...
Cheers,
Ben.
^ permalink raw reply
* [PATCH] powerpc/ptrace: Remove BUG_ON when full register set not available
From: Benjamin Herrenschmidt @ 2011-03-21 0:18 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mike Wolf
From: Mike Wolf <mjw@linux.vnet.ibm.com>
In some cases during a threaded core dump not all the threads will have
a full register set. This happens when the signal causing the core dump
races with a thread exiting. The race happens when the exiting thread
has entered the kernel for the last time before the signal arrives, but
doesn't get far enough through the exit code to avoid being included
in the core dump.
So we get a thread included in the core dump which is never going to go
out to userspace again and only has a partial register set recorded
Normally we would catch each thread as it is about to go into userspace
and capture the full register set then.
However, this exiting thread is never going to go out to userspace
again, so we have no way to capture its full register set. It doesn't
really matter, though, as this is a thread which is effectively
already dead.
So instead of hitting a BUG() in this case (a really bad choice of
action in the first place), we use a poison value for the register
values.
[BenH]: Some cosmetic/stylistic changes and fix build on ppc32
Signed-off-by: Mike Wolf <mjw@linux.vnet.ibm.com>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
---
arch/powerpc/include/asm/ptrace.h | 2 ++
arch/powerpc/kernel/ptrace.c | 15 ++++++++++++---
2 files changed, 14 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/ptrace.h b/arch/powerpc/include/asm/ptrace.h
index 0175a67..48223f9 100644
--- a/arch/powerpc/include/asm/ptrace.h
+++ b/arch/powerpc/include/asm/ptrace.h
@@ -125,8 +125,10 @@ extern int ptrace_put_reg(struct task_struct *task, int regno,
#endif /* ! __powerpc64__ */
#define TRAP(regs) ((regs)->trap & ~0xF)
#ifdef __powerpc64__
+#define NV_REG_POISON 0xdeadbeefdeadbeefUL
#define CHECK_FULL_REGS(regs) BUG_ON(regs->trap & 1)
#else
+#define NV_REG_POISON 0xdeadbeef
#define CHECK_FULL_REGS(regs) \
do { \
if ((regs)->trap & 1) \
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 9065369..895b082 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -229,12 +229,16 @@ static int gpr_get(struct task_struct *target, const struct user_regset *regset,
unsigned int pos, unsigned int count,
void *kbuf, void __user *ubuf)
{
- int ret;
+ int i, ret;
if (target->thread.regs == NULL)
return -EIO;
- CHECK_FULL_REGS(target->thread.regs);
+ if (!FULL_REGS(target->thread.regs)) {
+ /* We have a partial register set. Fill 14-31 with bogus values */
+ for (i = 14; i < 32; i++)
+ target->thread.regs->gpr[i] = NV_REG_POISON;
+ }
ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
target->thread.regs,
@@ -641,11 +645,16 @@ static int gpr32_get(struct task_struct *target,
compat_ulong_t *k = kbuf;
compat_ulong_t __user *u = ubuf;
compat_ulong_t reg;
+ int i;
if (target->thread.regs == NULL)
return -EIO;
- CHECK_FULL_REGS(target->thread.regs);
+ if (!FULL_REGS(target->thread.regs)) {
+ /* We have a partial register set. Fill 14-31 with bogus values */
+ for (i = 14; i < 32; i++)
+ target->thread.regs->gpr[i] = NV_REG_POISON;
+ }
pos /= sizeof(reg);
count /= sizeof(reg);
^ permalink raw reply related
* Re: [PATCH v2] powerpc/ptrace: remove BUG_ON when full register set not available
From: Benjamin Herrenschmidt @ 2011-03-21 0:15 UTC (permalink / raw)
To: mjw; +Cc: linuxppc-dev, mikey, anton
In-Reply-To: <1300282642.15145.2.camel@w500>
On Wed, 2011-03-16 at 08:37 -0500, Michael Wolf wrote:
> In some cases during a threaded core dump not all
> the threads will have a full register set. This
> will cause problems when the sigkill is sent to
> the thread. To solve this problem a poison value
> (0xdeadbeef) will be placed in the buffer in place
> of the actual register values. This will affect
> gpr14 to gpr31.
>
> Signed-off-by: Mike Wolf <mjw@linux.vnet.ibm.com>
Patch is busted on ppc32 (you add #define's in the middle of a
multi-line macro) and of doubtful stylistic value :-) I'll merge
a slightly reworked variant that includes a new cset comment
with Paulus explanation in it.
Cheers,
Ben.
> ----------
> --- linux-2.6.32-71.el6.ppc64.orig/arch/powerpc/include/asm/ptrace.h 2010-08-31 23:56:50.000000000 -0500
> +++ linux-2.6.32-71.el6.ppc64/arch/powerpc/include/asm/ptrace.h 2011-03-14 11:43:33.176667099 -0500
> @@ -123,8 +123,14 @@ extern int ptrace_put_reg(struct task_st
> #define TRAP(regs) ((regs)->trap & ~0xF)
> #ifdef __powerpc64__
> #define CHECK_FULL_REGS(regs) BUG_ON(regs->trap & 1)
> +#define PARTIAL_REG_FILL 0xdeadbeefdeadbeefUL
> +#define PARTIAL_REG_START 14
> +#define PARTIAL_REG_END 31
> #else
> #define CHECK_FULL_REGS(regs) \
> +#define PARTIAL_REG_FILL 0xdeadbeef
> +#define PARTIAL_REG_START 14
> +#define PARTIAL_REG_END 31
> do { \
> if ((regs)->trap & 1) \
> printk(KERN_CRIT "%s: partial register set\n", __func__); \
> --- linux-2.6.32-71.el6.ppc64.orig/arch/powerpc/kernel/ptrace.c 2009-12-02 21:51:21.000000000 -0600
> +++ linux-2.6.32-71.el6.ppc64/arch/powerpc/kernel/ptrace.c 2011-03-14 13:01:51.955586126 -0500
> @@ -125,11 +125,16 @@ static int gpr_get(struct task_struct *t
> void *kbuf, void __user *ubuf)
> {
> int ret;
> + int partial_reg;
>
> if (target->thread.regs == NULL)
> return -EIO;
>
> - CHECK_FULL_REGS(target->thread.regs);
> + if (!FULL_REGS(target->thread.regs))
> + /* We have a partial register set. Fill 14-31 with bogus values */
> + for(partial_reg=PARTIAL_REG_START;partial_reg <= PARTIAL_REG_END;
> + partial_reg++)
> + target->thread.regs->gpr[partial_reg] = PARTIAL_REG_FILL;
>
> ret = user_regset_copyout(&pos, &count, &kbuf, &ubuf,
> target->thread.regs,
> @@ -536,11 +541,16 @@ static int gpr32_get(struct task_struct
> compat_ulong_t *k = kbuf;
> compat_ulong_t __user *u = ubuf;
> compat_ulong_t reg;
> + int partial_reg;
>
> if (target->thread.regs == NULL)
> return -EIO;
>
> - CHECK_FULL_REGS(target->thread.regs);
> + if (!FULL_REGS(target->thread.regs))
> + /* We have a partial register set. Fill 14-31 with bogus values */
> + for(partial_reg=PARTIAL_REG_START;partial_reg <= PARTIAL_REG_END;
> + partial_reg++)
> + target->thread.regs->gpr[partial_reg] = PARTIAL_REG_FILL;
>
> pos /= sizeof(reg);
> count /= sizeof(reg);
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
^ permalink raw reply
* Re: mmotm threatens ppc preemption again
From: Benjamin Herrenschmidt @ 2011-03-20 23:53 UTC (permalink / raw)
To: Hugh Dickins
Cc: Jeremy Fitzhardinge, linuxppc-dev, Andrew Morton, Peter Zijlstra
In-Reply-To: <alpine.LSU.2.00.1103192041390.1592@sister.anvils>
On Sat, 2011-03-19 at 21:11 -0700, Hugh Dickins wrote:
>
> As I warned a few weeks ago, Jeremy has vmalloc apply_to_pte_range
> patches in mmotm, which again assault PowerPC's expectations, and
> cause lots of noise with CONFIG_PREEMPT=y CONFIG_PREEMPT_DEBUG=y.
>
> This time in vmalloc as well as vfree; and Peter's fix to the last
> lot, which went into 2.6.38, doesn't protect against these ones.
> Here's what I now see when I swapon and swapoff:
Right. And we said from day one we had the HARD WIRED assumption that
arch_enter/leave_lazy_mmu_mode() was ALWAYS going to be called within
a PTE lock section, and we did get reassurance that it was going to
remain so.
So why is it ok for them to change those and break us like that ?
Seriously, this is going out of control. If we can't even rely on
fundamental locking assumptions in the VM to remain reasonably stable
or at least get some amount of -care- from who changes them as to
whether they break others and work with us to fix them, wtf ?
I don't know what the right way to fix that is. We have an absolute
requirement that the batching we start within a lazy MMU section
is complete and flushed before any other PTE in that section can be
touched by anything else. Do we -at least- keep that guarantee ?
If yes, then maybe preempt_disable/enable() around
arch_enter/leave_lazy_mmu_mode() in apply_to_pte_range() would do...
Or maybe I should just prevent any batching of init_mm :-(
Cheers,
Ben.
^ permalink raw reply
* PowerMac7,3 dvd drive?
From: kevin diggs @ 2011-03-20 23:52 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I am seeing ... issues with the optical drive (hda) under 2.6.36. I
can't mount disks:
[root@PowerMacG5 ~]# mount -r /dev/hda /mnt/cdrom
mount: /dev/hda already mounted or /mnt/cdrom busy
The log has:
[ 239.922268] hda: irq timeout: status=0xd0 { Busy }
[ 239.922485] hda: possibly failed opcode: 0xa0
eject hda will hang ... longer than my patience.
At first I thought the drive was going south. But I don't see this (at
least so far) on 2.6.28.
Thanks!
kevin
^ permalink raw reply
* Re: powerpc/pci sysdata batch hangs G5 boot
From: Benjamin Herrenschmidt @ 2011-03-20 9:10 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, Hugh Dickins
In-Reply-To: <AANLkTikMbMqSRpt9gCrHgzpJuRCGL7rfLAs6erJL0Qjc@mail.gmail.com>
On Sun, 2011-03-20 at 00:25 -0600, Grant Likely wrote:
> On Sat, Mar 19, 2011 at 9:41 PM, Hugh Dickins <hughd@google.com> wrote:
> > Hi Grant,
> >
> > I've been unable to boot mmotm on the G5 for a few weeks; and now that
> > the problem has reached Linus, I've bisected and it converges on your:
> >
> > commit b5d937de0367d26f65b9af1aef5f2c34c1939be0
> > powerpc/pci: Make both ppc32 and ppc64 use sysdata for pci_controller
>
> Hi Hugh,
>
> Thanks for the testing. I don't have access to a G5 unfortunately.
> Are you able to capture the good/bad console output and send it to me?
> A digital photo would be fine if you can't grab the raw text. Add
> #define DEBUG to the top of arch/powerpc/kernel/pci-common.c above the
> #includes too if you don't mind.
>
> I'm investigating on my end. I suspect that I've messed up retrieval
> of the hose pointer.
Hrm, you merged that already ? I would have liked to have a chance to at
least test and review properly...
Oh well, I have G5's here, I'll see if I can find what's wrong tomorrow.
Cheers,
Ben.
^ permalink raw reply
* Re: powerpc/pci sysdata batch hangs G5 boot
From: Grant Likely @ 2011-03-20 6:25 UTC (permalink / raw)
To: Hugh Dickins; +Cc: linuxppc-dev
In-Reply-To: <alpine.LSU.2.00.1103192023140.1592@sister.anvils>
On Sat, Mar 19, 2011 at 9:41 PM, Hugh Dickins <hughd@google.com> wrote:
> Hi Grant,
>
> I've been unable to boot mmotm on the G5 for a few weeks; and now that
> the problem has reached Linus, I've bisected and it converges on your:
>
> commit b5d937de0367d26f65b9af1aef5f2c34c1939be0
> =A0 =A0powerpc/pci: Make both ppc32 and ppc64 use sysdata for pci_control=
ler
Hi Hugh,
Thanks for the testing. I don't have access to a G5 unfortunately.
Are you able to capture the good/bad console output and send it to me?
A digital photo would be fine if you can't grab the raw text. Add
#define DEBUG to the top of arch/powerpc/kernel/pci-common.c above the
#includes too if you don't mind.
I'm investigating on my end. I suspect that I've messed up retrieval
of the hose pointer.
Thanks,
g.
^ 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