* [RFC PATCH 0/9] Machine check handling in linux host.
From: Mahesh J Salgaonkar @ 2013-08-07 9:37 UTC (permalink / raw)
To: linuxppc-dev, Benjamin Herrenschmidt
Cc: Jeremy Kerr, Paul Mackerras, Anton Blanchard
Hi,
Please find the patch set that performs the machine check handling inside linux
host. The design is to be able to handle re-entrancy so that we do not clobber
the machine check information during nested machine check interrupt.
The patch 2 implements the logic to save the raw MCE info onto the emergency
stack and prepares to take another exception. Patch 3 and 4 adds CPU-side hooks
for early machine check handler and TLB flush. The patch 5 and 6 is
responsible to detect SLB/TLB errors and flush them off in the real mode. The
patch 7 implements the logic to decode and save high level MCE information to
per cpu buffer without clobbering. The patch 9 adds the basic error handling to
the high level C code with MMU on.
I have tested SLB multihit scenario on powernv. For TLB multihit and nested
machine check testing, I am still working on getting cronus setup to be able
to inject errors.
Please review and let me know your comments.
Thanks,
-Mahesh.
---
Mahesh Salgaonkar (9):
powerpc: Split the common exception prolog logic into two section.
powerpc: handle machine check in Linux host.
powerpc: Introduce a early machine check hook in cpu_spec.
powerpc: Add flush_tlb operation in cpu_spec.
powerpc: Flush SLB/TLBs if we get SLB/TLB machine check errors on power7.
powerpc: Flush SLB/TLBs if we get SLB/TLB machine check errors on power8.
powerpc: Decode and save machine check event.
powerpc/powernv: Remove machine check handling in OPAL.
powerpc/powernv: Machine check exception handling.
arch/powerpc/include/asm/bitops.h | 5 +
arch/powerpc/include/asm/cputable.h | 12 +
arch/powerpc/include/asm/exception-64s.h | 110 ++++++++---
arch/powerpc/include/asm/mce.h | 190 ++++++++++++++++++++
arch/powerpc/kernel/Makefile | 3
arch/powerpc/kernel/cpu_setup_power.S | 39 +++-
arch/powerpc/kernel/cputable.c | 16 ++
arch/powerpc/kernel/exceptions-64s.S | 50 +++++
arch/powerpc/kernel/mce.c | 179 +++++++++++++++++++
arch/powerpc/kernel/mce_power.c | 287 ++++++++++++++++++++++++++++++
arch/powerpc/kernel/traps.c | 15 ++
arch/powerpc/kvm/book3s_hv_ras.c | 42 +---
arch/powerpc/platforms/powernv/opal.c | 84 ++++++---
13 files changed, 935 insertions(+), 97 deletions(-)
create mode 100644 arch/powerpc/include/asm/mce.h
create mode 100644 arch/powerpc/kernel/mce.c
create mode 100644 arch/powerpc/kernel/mce_power.c
--
-Mahesh
^ permalink raw reply
* Re: [PATCH 2/4] powerpc: Add new save_tar() register function.
From: Paul Mackerras @ 2013-08-07 8:07 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Matt Evans
In-Reply-To: <1375855918-3625-2-git-send-email-mikey@neuling.org>
On Wed, Aug 07, 2013 at 04:11:56PM +1000, Michael Neuling wrote:
> Add save_tar() function to save the Target Address Register (TAR). This will
> be used in a future patch to save the TAR earlier than it currently is.
>
> Signed-off-by: Michael Neuling <mikey@neuling.org>
> Cc: <stable@vger.kernel.org>
> ---
> arch/powerpc/include/asm/switch_to.h | 5 +++++
> arch/powerpc/kernel/entry_64.S | 12 ++++++++++++
> 2 files changed, 17 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h
> index 49a13e0..4531068 100644
> --- a/arch/powerpc/include/asm/switch_to.h
> +++ b/arch/powerpc/include/asm/switch_to.h
> @@ -15,6 +15,11 @@ extern struct task_struct *__switch_to(struct task_struct *,
> struct thread_struct;
> extern struct task_struct *_switch(struct thread_struct *prev,
> struct thread_struct *next);
> +#ifdef CONFIG_PPC_BOOK3S_64
> +extern void _save_tar(struct thread_struct *prev);
> +#else
> +static inline void _save_tar(struct thread_struct *prev) {}
> +#endif
>
> extern void giveup_fpu(struct task_struct *);
> extern void load_up_fpu(void);
> diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
> index 4674fe6..32e18f3 100644
> --- a/arch/powerpc/kernel/entry_64.S
> +++ b/arch/powerpc/kernel/entry_64.S
> @@ -389,6 +389,18 @@ DSCR_DEFAULT:
> .tc dscr_default[TC],dscr_default
>
> .section ".text"
> +#ifdef CONFIG_PPC_BOOK3S_64
> +_GLOBAL(_save_tar)
> + /*
> + * Back up the TAR across context switches. Note that the TAR is not
> + * available for use in the kernel. (To provide this, the TAR should
> + * be backed up/restored on exception entry/exit instead, and be in
> + * pt_regs. FIXME, this should be in pt_regs anyway (for debug).)
> + */
> + mfspr r0,SPRN_TAR
> + std r0,THREAD_TAR(r3)
> + blr
> +#endif
Why not do this in C, as in prev->tar = mfspr(SPRN_TAR); ?
Paul.
^ permalink raw reply
* Re: [PATCH v4 00/31] add COMMON_CLK support for PowerPC MPC512x
From: Gerhard Sittig @ 2013-08-07 7:36 UTC (permalink / raw)
To: linuxppc-dev, Anatolij Gustschin, Mike Turquette,
linux-arm-kernel, devicetree, Wolfram Sang, Mauro Carvalho Chehab,
David Woodhouse, Wolfgang Grandegger, Marc Kleine-Budde,
Pantelis Antoniou, Mark Brown, Greg Kroah-Hartman, Rob Herring,
Detlev Zundel
In-Reply-To: <20130806213148.GS2580@book.gsilab.sittig.org>
[ no change in content, but order shuffling for better application ]
On Tue, Aug 06, 2013 at 23:31 +0200, Gerhard Sittig wrote:
>
> [ this is an overview on how to split the series if necessary ]
>
> On Tue, Aug 06, 2013 at 22:43 +0200, Gerhard Sittig wrote:
> >
> > this series
> > - fixes several drivers that are used in the MPC512x platform (UART,
> > SPI, ethernet, PCI, USB, CAN, NAND flash, video capture) in how they
> > handle clocks (appropriately acquire and setup them, hold references
> > during use, release clocks after use)
> > - introduces support for the common clock framework (CCF, COMMON_CLK
> > Kconfig option) in the PowerPC based MPC512x platform, which brings
> > device tree based clock lookup as well
> >
> > although the series does touch several subsystems -- tty (serial), spi,
> > net (can, fs_enet), mtd (nfc), usb, i2c, media (viu), and dts -- all of
> > the patches are strictly clock related or trivial
> >
> > it appears most appropriate to take this series through either the clk
> > or the powerpc trees after it has passed review and other subsystem
> > maintainers ACKed the clock setup related driver modifications
>
> It was suggested that the series may not be kept together when
> applying, i.e. that individual patches may need to take separate
> routes through individual subsystem trees.
>
> Here is how the parts of the series interact:
> - parts 01-14 are apparent fixes and improvements to existing
> drivers, they may immediately get applied via their respective
> subsystems when they are considered acceptable in review
> (number 13 already was taken into clk-next)
> - parts 15-16 are device tree improvements (providing previously
> lacking information on the hardware, plus introducing support
> for symbolic references in DT nodes), and can get applied
> immediately via their respective subsystem
> - part 17 introduces the platform clock driver which provides
> common clock support (uses shared drivers and common
> infrastructure, is an OF clock provider) -- this patch
> introduces _and_ enables the driver which strictly depends on
> the device tree update from part 16, and when common clock
> support gets enabled all peripheral drivers shall have received
> their clock API use cleanup
> - part 18 introduces clock specs in the device tree which is used
> for client side lookups (from within peripheral drivers), this
> part must not get applied before the OF clock provider from
> part 17
> - parts 19-21 and 23-28 further adjust peripheral drivers _after_
> the common clock support and OF clock lookup have become
> available, they strictly depend on parts 17 and 18, finally
> bring peripheral drivers into the common clock world and remove
> workarounds in the backend which support migration
> - parts 22 and 29-31 finally remove remaining compat and
> migration stuff that has become obsolete after everything else
> was adjusted (I'd happily re-spin the series to move 22 to the
> end if eliminating this seemingly out-of-order item helps,
> currently it's at that position since it finishes what patch 20
> and 21 have prepared, while I did not dare to squash SPI and
> UART related patches since they reside in different subsystems)
>
> The above results in the following stages, when the series needs
> to get split:
> - parts 01-16 could be taken immediately and need not be kept in
> any order, as they don't depend on each other
> - parts 17-18 could be taken after 01-16 all are in place (while
> 18 requires 17)
> - parts 19-28 (see the remark on 22) could be taken after 17 and
> 18 are in place (22 depends on 20 and 21 but may get moved to
> any later position at will, all other parts don't depend on
> each other and can get applied in any order)
> - parts 29-31 (and 22 if not applied so far) could be taken after
> all parts up to 28 were applied
Here I erred. The order of the patches within phase 3 appears to
actually matter. I'm sorry for bothering you again.
While the _content_ of the patches (which manipulation gets done
to the source) is correct and independent from neighbour patches,
yet a patch in that third phase will change the _context_ of
subsequent patches. The sum of all the patches applied will be
identical again, but changed order of application may cause
conflicts (regardless of how simple to resolve they may be).
Build and run tests and the organization of v4 (immediate removal
upon driver adjustment) have shown that removing a migration
workaround in the very moment where driver adjustment obsoletes
it keeps the system operational. I consider this a very positive
feature, and would only rearrange the order if the series'
content was ACKed in complete.
Moving removal of the workarounds to a later point in time won't
affect operation (just leaves the workaround in place a little
longer, while it does not harm), and will eliminate potential for
conflicts. This I would do when accepting the series was
decided, to not lose the precious test feature during
development.
A byproduct of this rearrangement is that patches in phase 3
won't any longer touch a peripheral driver _and_ the clock driver
within a single patch, for whatever that may be worth.
So I suggest the following:
I can move parts 19 and 22 (completely) and the "workaround
removal" aspect of parts 20-21 and 23-28 to a later point in the
sequence, maybe squash them with part 31 (cleanup after migration
has completed).
This allows for even better (conflict free) application of the
series through individual and most appropriate trees. All of
this of course assumes that the series passes review, and that
you agree on the outlined application in four phases if the
series cannot be kept together:
- clock API use cleanup for peripheral drivers, and device tree
update to provide previously missing hardware information
- introduction of the platform clock driver and OF clock lookup
- adjustment of peripheral drivers after common clock support has
become available
- removal of migration support and compat workarounds after
migration has completed
> Please consider that I'm not trying to be pushy :) but that I
> want to provide all the possible help and information on how the
> series might get applied, assuming that it will pass review. So
> far there has not been objection, all feedback got addressed,
> while explicit ACKs still are pending.
>
> For your reference here is the stats and the (numbered) list of
> files again:
>
> 0000-cover-letter.patch
> 0001-spi-mpc512x-cleanup-clock-API-use.patch
> 0002-serial-mpc512x-cleanup-clock-API-use.patch
> 0003-USB-fsl-mph-dr-of-cleanup-clock-API-use.patch
> 0004-mtd-mpc5121_nfc-cleanup-clock-API-use.patch
> 0005-media-fsl-viu-cleanup-clock-API-use.patch
> 0006-i2c-mpc-cleanup-clock-API-use.patch
> 0007-fs_enet-silence-a-build-warning-unused-variable.patch
> 0008-fs_enet-cleanup-clock-API-use.patch
> 0009-powerpc-fsl-pci-improve-clock-API-use.patch
> 0010-net-can-mscan-add-a-comment-on-reg-to-idx-mapping.patch
> 0011-net-can-mscan-improve-clock-API-use.patch
> 0012-powerpc-mpc512x-array-decl-for-MCLK-registers-in-CCM.patch
> 0013-clk-wrap-I-O-access-for-improved-portability.patch
> 0014-dts-mpc512x-prepare-for-preprocessor-support.patch
> 0015-dts-mpc512x-introduce-dt-bindings-clock-header.patch
> 0016-dts-mpc512x-add-clock-related-device-tree-specs.patch
> 0017-clk-mpc512x-introduce-COMMON_CLK-for-MPC512x.patch
> 0018-dts-mpc512x-add-clock-specs-for-client-lookups.patch
> 0019-clk-mpc512x-don-t-pre-enable-FEC-and-I2C-clocks.patch
> 0020-spi-mpc512x-switch-to-CCF-names-in-clock-lookup.patch
> 0021-serial-mpc512x-switch-to-CCF-names-in-clock-lookup.patch
> 0022-clk-mpc512x-remove-PSC-UART-SPI-compat-workarounds.patch
> 0023-serial-mpc512x-setup-the-PSC-FIFO-clock-as-well.patch
> 0024-USB-fsl-mph-dr-of-remove-now-obsolete-clock-lookup-n.patch
> 0025-mtd-mpc5121_nfc-remove-now-obsolete-clock-lookup-nam.patch
> 0026-media-fsl-viu-remove-now-obsolete-clock-lookup-name.patch
> 0027-net-can-mscan-add-common-clock-support-for-mpc512x.patch
> 0028-powerpc-mpc512x-improve-DIU-related-clock-setup.patch
> 0029-clk-mpc512x-switch-to-COMMON_CLK-remove-PPC_CLOCK.patch
> 0030-net-can-mscan-remove-non-CCF-code-for-MPC512x.patch
> 0031-clk-mpc512x-remove-remaining-migration-workarounds.patch
>
> > Gerhard Sittig (31):
> > spi: mpc512x: cleanup clock API use
> > serial: mpc512x: cleanup clock API use
> > USB: fsl-mph-dr-of: cleanup clock API use
> > mtd: mpc5121_nfc: cleanup clock API use
> > [media] fsl-viu: cleanup clock API use
> > i2c: mpc: cleanup clock API use
> > fs_enet: silence a build warning (unused variable)
> > fs_enet: cleanup clock API use
> > powerpc/fsl-pci: improve clock API use
> > net: can: mscan: add a comment on reg to idx mapping
> > net: can: mscan: improve clock API use
> > powerpc: mpc512x: array decl for MCLK registers in CCM
> > clk: wrap I/O access for improved portability
> > dts: mpc512x: prepare for preprocessor support
> > dts: mpc512x: introduce dt-bindings/clock/ header
> > dts: mpc512x: add clock related device tree specs
> > clk: mpc512x: introduce COMMON_CLK for MPC512x
> > dts: mpc512x: add clock specs for client lookups
> > clk: mpc512x: don't pre-enable FEC and I2C clocks
> > spi: mpc512x: switch to CCF names in clock lookup
> > serial: mpc512x: switch to CCF names in clock lookup
> > clk: mpc512x: remove PSC (UART, SPI) compat workarounds
> > serial: mpc512x: setup the PSC FIFO clock as well
> > USB: fsl-mph-dr-of: remove now obsolete clock lookup name
> > mtd: mpc5121_nfc: remove now obsolete clock lookup name
> > [media] fsl-viu: remove now obsolete clock lookup name
> > net: can: mscan: add common clock support for mpc512x
> > powerpc/mpc512x: improve DIU related clock setup
> > clk: mpc512x: switch to COMMON_CLK, remove PPC_CLOCK
> > net: can: mscan: remove non-CCF code for MPC512x
> > clk: mpc512x: remove remaining migration workarounds
> >
> > arch/powerpc/boot/dts/ac14xx.dts | 9 +-
> > arch/powerpc/boot/dts/include/dt-bindings | 1 +
> > arch/powerpc/boot/dts/mpc5121.dtsi | 110 ++-
> > arch/powerpc/boot/dts/mpc5121ads.dts | 2 +-
> > arch/powerpc/boot/dts/pdm360ng.dts | 2 +-
> > arch/powerpc/include/asm/mpc5121.h | 18 +-
> > arch/powerpc/platforms/512x/Kconfig | 2 +-
> > arch/powerpc/platforms/512x/Makefile | 3 +-
> > arch/powerpc/platforms/512x/clock-commonclk.c | 716 +++++++++++++++++++
> > arch/powerpc/platforms/512x/clock.c | 753 --------------------
> > arch/powerpc/platforms/512x/mpc512x_shared.c | 165 +++--
> > arch/powerpc/sysdev/fsl_pci.c | 22 +
> > drivers/clk/clk-divider.c | 6 +-
> > drivers/clk/clk-gate.c | 6 +-
> > drivers/clk/clk-mux.c | 6 +-
> > drivers/i2c/busses/i2c-mpc.c | 24 +
> > drivers/media/platform/fsl-viu.c | 23 +-
> > drivers/mtd/nand/mpc5121_nfc.c | 21 +-
> > drivers/net/can/mscan/mpc5xxx_can.c | 281 +++++---
> > drivers/net/can/mscan/mscan.c | 27 +-
> > drivers/net/can/mscan/mscan.h | 3 +
> > .../net/ethernet/freescale/fs_enet/fs_enet-main.c | 21 +-
> > drivers/spi/spi-mpc512x-psc.c | 60 +-
> > drivers/tty/serial/mpc52xx_uart.c | 179 ++++-
> > drivers/usb/host/fsl-mph-dr-of.c | 27 +-
> > include/dt-bindings/clock/mpc512x-clock.h | 69 ++
> > include/linux/clk-provider.h | 33 +
> > include/linux/fs_enet_pd.h | 3 +
> > 28 files changed, 1534 insertions(+), 1058 deletions(-)
> > create mode 120000 arch/powerpc/boot/dts/include/dt-bindings
> > create mode 100644 arch/powerpc/platforms/512x/clock-commonclk.c
> > delete mode 100644 arch/powerpc/platforms/512x/clock.c
> > create mode 100644 include/dt-bindings/clock/mpc512x-clock.h
virtually yours
Gerhard Sittig
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr. 5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: office@denx.de
^ permalink raw reply
* Re: [PATCH v4 11/31] net: can: mscan: improve clock API use
From: Marc Kleine-Budde @ 2013-08-07 7:35 UTC (permalink / raw)
To: Gerhard Sittig
Cc: devicetree, Mike Turquette, Detlev Zundel, Wolfram Sang,
David Woodhouse, Greg Kroah-Hartman, Rob Herring, Mark Brown,
Wolfgang Grandegger, Anatolij Gustschin, linuxppc-dev,
linux-arm-kernel, Mauro Carvalho Chehab
In-Reply-To: <5201F7A7.90906@pengutronix.de>
[-- Attachment #1: Type: text/plain, Size: 739 bytes --]
On 08/07/2013 09:30 AM, Marc Kleine-Budde wrote:
> On 08/06/2013 10:43 PM, Gerhard Sittig wrote:
>> the .get_clock() callback is run from probe() and might allocate
>> resources, introduce a .put_clock() callback that is run from remove()
>> to undo any allocation activities
>
> AFAICS With this patch put_clock() is still a no-op, is there a patch
> which adds some code there? If not, please remove.
I missed patch 27.
sorry for the noise.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH v4 11/31] net: can: mscan: improve clock API use
From: Marc Kleine-Budde @ 2013-08-07 7:30 UTC (permalink / raw)
To: Gerhard Sittig
Cc: devicetree, Mike Turquette, Detlev Zundel, Wolfram Sang,
David Woodhouse, Greg Kroah-Hartman, Rob Herring, Mark Brown,
Wolfgang Grandegger, Anatolij Gustschin, linuxppc-dev,
linux-arm-kernel, Mauro Carvalho Chehab
In-Reply-To: <1375821851-31609-12-git-send-email-gsi@denx.de>
[-- Attachment #1: Type: text/plain, Size: 636 bytes --]
On 08/06/2013 10:43 PM, Gerhard Sittig wrote:
> the .get_clock() callback is run from probe() and might allocate
> resources, introduce a .put_clock() callback that is run from remove()
> to undo any allocation activities
AFAICS With this patch put_clock() is still a no-op, is there a patch
which adds some code there? If not, please remove.
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH v4 11/31] net: can: mscan: improve clock API use
From: Marc Kleine-Budde @ 2013-08-07 7:28 UTC (permalink / raw)
To: Gerhard Sittig
Cc: devicetree, Mike Turquette, Detlev Zundel, Wolfram Sang,
David Woodhouse, Greg Kroah-Hartman, Rob Herring, Mark Brown,
Wolfgang Grandegger, Anatolij Gustschin, linuxppc-dev,
linux-arm-kernel, Mauro Carvalho Chehab
In-Reply-To: <1375821851-31609-12-git-send-email-gsi@denx.de>
[-- Attachment #1: Type: text/plain, Size: 5490 bytes --]
On 08/06/2013 10:43 PM, Gerhard Sittig wrote:
> the .get_clock() callback is run from probe() and might allocate
> resources, introduce a .put_clock() callback that is run from remove()
> to undo any allocation activities
>
> prepare and enable the clocks in open(), disable and unprepare the
> clocks in close() if clocks were acquired during probe(), to not assume
> knowledge about which activities are done in probe() and remove()
>
> use devm_get_clk() to lookup the SYS and REF clocks, to have the clocks
> put upon device shutdown
>
> store pointers to data structures upon successful allocation already
> instead of deferral until complete setup, such that subroutines in the
> setup sequence may access those data structures as well to track their
> resource acquisition
>
> since clock allocation remains optional, the release callback as well as
> the enable/disable calls in open/close are optional as well
>
> Signed-off-by: Gerhard Sittig <gsi@denx.de>
> ---
> drivers/net/can/mscan/mpc5xxx_can.c | 18 ++++++++++++------
> drivers/net/can/mscan/mscan.c | 27 ++++++++++++++++++++++++++-
> drivers/net/can/mscan/mscan.h | 3 +++
> 3 files changed, 41 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/net/can/mscan/mpc5xxx_can.c b/drivers/net/can/mscan/mpc5xxx_can.c
> index bc422ba..e59b3a3 100644
> --- a/drivers/net/can/mscan/mpc5xxx_can.c
> +++ b/drivers/net/can/mscan/mpc5xxx_can.c
> @@ -40,6 +40,7 @@ struct mpc5xxx_can_data {
> unsigned int type;
> u32 (*get_clock)(struct platform_device *ofdev, const char *clock_name,
> int *mscan_clksrc);
> + void (*put_clock)(struct platform_device *ofdev);
> };
>
> #ifdef CONFIG_PPC_MPC52xx
> @@ -180,7 +181,7 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
> clockdiv = 1;
>
> if (!clock_name || !strcmp(clock_name, "sys")) {
> - sys_clk = clk_get(&ofdev->dev, "sys_clk");
> + sys_clk = devm_clk_get(&ofdev->dev, "sys_clk");
> if (IS_ERR(sys_clk)) {
> dev_err(&ofdev->dev, "couldn't get sys_clk\n");
> goto exit_unmap;
> @@ -203,7 +204,7 @@ static u32 mpc512x_can_get_clock(struct platform_device *ofdev,
> }
>
> if (clocksrc < 0) {
> - ref_clk = clk_get(&ofdev->dev, "ref_clk");
> + ref_clk = devm_clk_get(&ofdev->dev, "ref_clk");
> if (IS_ERR(ref_clk)) {
> dev_err(&ofdev->dev, "couldn't get ref_clk\n");
> goto exit_unmap;
> @@ -280,6 +281,8 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
> dev = alloc_mscandev();
> if (!dev)
> goto exit_dispose_irq;
> + platform_set_drvdata(ofdev, dev);
> + SET_NETDEV_DEV(dev, &ofdev->dev);
>
> priv = netdev_priv(dev);
> priv->reg_base = base;
> @@ -296,8 +299,6 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
> goto exit_free_mscan;
> }
>
> - SET_NETDEV_DEV(dev, &ofdev->dev);
> -
> err = register_mscandev(dev, mscan_clksrc);
> if (err) {
> dev_err(&ofdev->dev, "registering %s failed (err=%d)\n",
> @@ -305,8 +306,6 @@ static int mpc5xxx_can_probe(struct platform_device *ofdev)
> goto exit_free_mscan;
> }
>
> - platform_set_drvdata(ofdev, dev);
> -
> dev_info(&ofdev->dev, "MSCAN at 0x%p, irq %d, clock %d Hz\n",
> priv->reg_base, dev->irq, priv->can.clock.freq);
>
> @@ -324,10 +323,17 @@ exit_unmap_mem:
>
> static int mpc5xxx_can_remove(struct platform_device *ofdev)
> {
> + const struct of_device_id *match;
> + const struct mpc5xxx_can_data *data;
> struct net_device *dev = platform_get_drvdata(ofdev);
> struct mscan_priv *priv = netdev_priv(dev);
>
> + match = of_match_device(mpc5xxx_can_table, &ofdev->dev);
> + data = match ? match->data : NULL;
> +
> unregister_mscandev(dev);
> + if (data && data->put_clock)
> + data->put_clock(ofdev);
> iounmap(priv->reg_base);
> irq_dispose_mapping(dev->irq);
> free_candev(dev);
> diff --git a/drivers/net/can/mscan/mscan.c b/drivers/net/can/mscan/mscan.c
> index e6b4095..4f998f5 100644
> --- a/drivers/net/can/mscan/mscan.c
> +++ b/drivers/net/can/mscan/mscan.c
> @@ -573,10 +573,24 @@ static int mscan_open(struct net_device *dev)
> struct mscan_priv *priv = netdev_priv(dev);
> struct mscan_regs __iomem *regs = priv->reg_base;
>
> + if (priv->clk_ipg) {
> + ret = clk_prepare_enable(priv->clk_ipg);
> + if (ret)
> + goto exit_retcode;
> + }
> + if (priv->clk_can) {
> + ret = clk_prepare_enable(priv->clk_can);
> + if (ret) {
> + if (priv->clk_ipg)
> + clk_disable_unprepare(priv->clk_ipg);
> + goto exit_retcode;
Why don't you add another jump label and jump to that to disable the
ipkg clock?
> + }
> + }
> +
> /* common open */
> ret = open_candev(dev);
> if (ret)
> - return ret;
> + goto exit_dis_clock;
>
> napi_enable(&priv->napi);
>
> @@ -604,6 +618,12 @@ exit_free_irq:
> exit_napi_disable:
> napi_disable(&priv->napi);
> close_candev(dev);
> +exit_dis_clock:
> + if (priv->clk_can)
> + clk_disable_unprepare(priv->clk_can);
> + if (priv->clk_ipg)
> + clk_disable_unprepare(priv->clk_ipg);
> +exit_retcode:
> return ret;
> }
Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* [PATCH v3] powerpc/eeh: powerpc/eeh: Fix undefined variable
From: Mike Qiu @ 2013-08-07 6:25 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mike Qiu, shangw
'pe_no' hasn't been defined, it should be an typo error,
it should be 'frozen_pe_no'.
Also '__func__' has missed in IODA_EEH_DBG(),
For safety reasons, use pr_devel() directly, instead
of use IODA_EEH_DBG()
Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 0cd1c4a..88d99ba 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -36,13 +36,6 @@
#include "powernv.h"
#include "pci.h"
-/* Debugging option */
-#ifdef IODA_EEH_DBG_ON
-#define IODA_EEH_DBG(args...) pr_info(args)
-#else
-#define IODA_EEH_DBG(args...)
-#endif
-
static char *hub_diag = NULL;
static int ioda_eeh_nb_init = 0;
@@ -823,17 +816,17 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
/* If OPAL API returns error, we needn't proceed */
if (rc != OPAL_SUCCESS) {
- IODA_EEH_DBG("%s: Invalid return value on "
- "PHB#%x (0x%lx) from opal_pci_next_error",
- __func__, hose->global_number, rc);
+ pr_devel("%s: Invalid return value on "
+ "PHB#%x (0x%lx) from opal_pci_next_error",
+ __func__, hose->global_number, rc);
continue;
}
/* If the PHB doesn't have error, stop processing */
if (err_type == OPAL_EEH_NO_ERROR ||
severity == OPAL_EEH_SEV_NO_ERROR) {
- IODA_EEH_DBG("%s: No error found on PHB#%x\n",
- __func__, hose->global_number);
+ pr_devel("%s: No error found on PHB#%x\n",
+ __func__, hose->global_number);
continue;
}
@@ -842,8 +835,9 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
* highest priority reported upon multiple errors on the
* specific PHB.
*/
- IODA_EEH_DBG("%s: Error (%d, %d, %d) on PHB#%x\n",
- err_type, severity, pe_no, hose->global_number);
+ pr_devel("%s: Error (%d, %d, %d) on PHB#%x\n",
+ __func__, err_type, severity,
+ frozen_pe_no, hose->global_number);
switch (err_type) {
case OPAL_EEH_IOC_ERROR:
if (severity == OPAL_EEH_SEV_IOC_DEAD) {
--
1.8.2.1
^ permalink raw reply related
* [PATCH 4/4] powerpc/tm: Save and restore checkpointed TAR, PPR and DSCR
From: Michael Neuling @ 2013-08-07 6:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Matt Evans
In-Reply-To: <1375855918-3625-1-git-send-email-mikey@neuling.org>
Currently we don't save and restore the checkpointed TAR, PPR and DSCR.
This adds the required save and restore to the treclaim and trechkpt code.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org>
---
arch/powerpc/kernel/tm.S | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/arch/powerpc/kernel/tm.S b/arch/powerpc/kernel/tm.S
index 51be8fb..0554d1f 100644
--- a/arch/powerpc/kernel/tm.S
+++ b/arch/powerpc/kernel/tm.S
@@ -233,6 +233,16 @@ dont_backup_fp:
std r5, _CCR(r7)
std r6, _XER(r7)
+
+ /* ******************** TAR, PPR, DSCR ********** */
+ mfspr r3, SPRN_TAR
+ mfspr r4, SPRN_PPR
+ mfspr r5, SPRN_DSCR
+
+ std r3, THREAD_TM_TAR(r12)
+ std r4, THREAD_TM_PPR(r12)
+ std r5, THREAD_TM_DSCR(r12)
+
/* MSR and flags: We don't change CRs, and we don't need to alter
* MSR.
*/
@@ -347,6 +357,16 @@ dont_restore_fp:
mtmsr r6 /* FP/Vec off again! */
restore_gprs:
+
+ /* ******************** TAR, PPR, DSCR ********** */
+ ld r4, THREAD_TM_TAR(r3)
+ ld r5, THREAD_TM_PPR(r3)
+ ld r6, THREAD_TM_DSCR(r3)
+
+ mtspr SPRN_TAR, r4
+ mtspr SPRN_PPR, r5
+ mtspr SPRN_DSCR, r6
+
/* ******************** CR,LR,CCR,MSR ********** */
ld r3, _CTR(r7)
ld r4, _LINK(r7)
--
1.8.1.2
^ permalink raw reply related
* [PATCH 3/4] powerpc: Save the TAR register earlier
From: Michael Neuling @ 2013-08-07 6:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Matt Evans
In-Reply-To: <1375855918-3625-1-git-send-email-mikey@neuling.org>
This moves us to use the save_tar() function to save the Target Address
Register (TAR) a lot earlier in __switch_to.
We need to save the TAR earlier as we may overwrite it in the transactional
memory reclaim/recheckpoint path.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org>
---
arch/powerpc/kernel/entry_64.S | 9 ---------
arch/powerpc/kernel/process.c | 6 ++++++
2 files changed, 6 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 32e18f3..616328e 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -461,15 +461,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_DSCR)
#ifdef CONFIG_PPC_BOOK3S_64
BEGIN_FTR_SECTION
- /*
- * Back up the TAR across context switches. Note that the TAR is not
- * available for use in the kernel. (To provide this, the TAR should
- * be backed up/restored on exception entry/exit instead, and be in
- * pt_regs. FIXME, this should be in pt_regs anyway (for debug).)
- */
- mfspr r0,SPRN_TAR
- std r0,THREAD_TAR(r3)
-
/* Event based branch registers */
mfspr r0, SPRN_BESCR
std r0, THREAD_BESCR(r3)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index c517dbe..6b4c649 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -600,6 +600,12 @@ struct task_struct *__switch_to(struct task_struct *prev,
struct ppc64_tlb_batch *batch;
#endif
+ /* Save the tar before we do treclaim/trecheckpoint as these
+ * will change the TAR
+ */
+ if (cpu_has_feature(CPU_FTR_ARCH_207S))
+ _save_tar(&prev->thread);
+
__switch_to_tm(prev);
#ifdef CONFIG_SMP
--
1.8.1.2
^ permalink raw reply related
* [PATCH 2/4] powerpc: Add new save_tar() register function.
From: Michael Neuling @ 2013-08-07 6:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Matt Evans
In-Reply-To: <1375855918-3625-1-git-send-email-mikey@neuling.org>
Add save_tar() function to save the Target Address Register (TAR). This will
be used in a future patch to save the TAR earlier than it currently is.
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org>
---
arch/powerpc/include/asm/switch_to.h | 5 +++++
arch/powerpc/kernel/entry_64.S | 12 ++++++++++++
2 files changed, 17 insertions(+)
diff --git a/arch/powerpc/include/asm/switch_to.h b/arch/powerpc/include/asm/switch_to.h
index 49a13e0..4531068 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -15,6 +15,11 @@ extern struct task_struct *__switch_to(struct task_struct *,
struct thread_struct;
extern struct task_struct *_switch(struct thread_struct *prev,
struct thread_struct *next);
+#ifdef CONFIG_PPC_BOOK3S_64
+extern void _save_tar(struct thread_struct *prev);
+#else
+static inline void _save_tar(struct thread_struct *prev) {}
+#endif
extern void giveup_fpu(struct task_struct *);
extern void load_up_fpu(void);
diff --git a/arch/powerpc/kernel/entry_64.S b/arch/powerpc/kernel/entry_64.S
index 4674fe6..32e18f3 100644
--- a/arch/powerpc/kernel/entry_64.S
+++ b/arch/powerpc/kernel/entry_64.S
@@ -389,6 +389,18 @@ DSCR_DEFAULT:
.tc dscr_default[TC],dscr_default
.section ".text"
+#ifdef CONFIG_PPC_BOOK3S_64
+_GLOBAL(_save_tar)
+ /*
+ * Back up the TAR across context switches. Note that the TAR is not
+ * available for use in the kernel. (To provide this, the TAR should
+ * be backed up/restored on exception entry/exit instead, and be in
+ * pt_regs. FIXME, this should be in pt_regs anyway (for debug).)
+ */
+ mfspr r0,SPRN_TAR
+ std r0,THREAD_TAR(r3)
+ blr
+#endif
/*
* This routine switches between two different tasks. The process
--
1.8.1.2
^ permalink raw reply related
* [PATCH 1/4] powerpc/tm: Add checkpointed versions of some SPRs to thread_struct
From: Michael Neuling @ 2013-08-07 6:11 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Matt Evans
Transactional memory will restore the TAR, PPR and DSCR on transaction failure.
Add these to the thread_struct for use in the future
Signed-off-by: Michael Neuling <mikey@neuling.org>
Cc: <stable@vger.kernel.org>
---
arch/powerpc/include/asm/processor.h | 4 ++++
arch/powerpc/kernel/asm-offsets.c | 3 +++
2 files changed, 7 insertions(+)
diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
index 47a35b0..e378ccc 100644
--- a/arch/powerpc/include/asm/processor.h
+++ b/arch/powerpc/include/asm/processor.h
@@ -247,6 +247,10 @@ struct thread_struct {
unsigned long tm_orig_msr; /* Thread's MSR on ctx switch */
struct pt_regs ckpt_regs; /* Checkpointed registers */
+ unsigned long tm_tar;
+ unsigned long tm_ppr;
+ unsigned long tm_dscr;
+
/*
* Transactional FP and VSX 0-31 register set.
* NOTE: the sense of these is the opposite of the integer ckpt_regs!
diff --git a/arch/powerpc/kernel/asm-offsets.c b/arch/powerpc/kernel/asm-offsets.c
index c7e8afc..8207459 100644
--- a/arch/powerpc/kernel/asm-offsets.c
+++ b/arch/powerpc/kernel/asm-offsets.c
@@ -138,6 +138,9 @@ int main(void)
DEFINE(THREAD_TM_TFHAR, offsetof(struct thread_struct, tm_tfhar));
DEFINE(THREAD_TM_TEXASR, offsetof(struct thread_struct, tm_texasr));
DEFINE(THREAD_TM_TFIAR, offsetof(struct thread_struct, tm_tfiar));
+ DEFINE(THREAD_TM_TAR, offsetof(struct thread_struct, tm_tar));
+ DEFINE(THREAD_TM_PPR, offsetof(struct thread_struct, tm_ppr));
+ DEFINE(THREAD_TM_DSCR, offsetof(struct thread_struct, tm_dscr));
DEFINE(PT_CKPT_REGS, offsetof(struct thread_struct, ckpt_regs));
DEFINE(THREAD_TRANSACT_VR0, offsetof(struct thread_struct,
transact_vr[0]));
--
1.8.1.2
^ permalink raw reply related
* Re: [PATCH 3/3] powerpc: check CPU_FTR_COHERENT_ICACHE in __flush_dcache_icache for 64bit kernel
From: Kevin Hao @ 2013-08-07 6:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1375785398.12557.62.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 997 bytes --]
On Tue, Aug 06, 2013 at 08:36:38PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-08-06 at 18:23 +0800, Kevin Hao wrote:
> > We don't need to flush the dcache and invalidate the icache on the
> > CPU which has CPU_FTR_COHERENT_ICACHE set.
>
> Actually we probably need an isync...
Will add.
Thanks,
Kevin
>
> Ben.
>
> > Signed-off-by: Kevin Hao <haokexin@gmail.com>
> > ---
> > arch/powerpc/kernel/misc_64.S | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> > index a781566..32e78e2 100644
> > --- a/arch/powerpc/kernel/misc_64.S
> > +++ b/arch/powerpc/kernel/misc_64.S
> > @@ -207,6 +207,9 @@ _GLOBAL(flush_inval_dcache_range)
> > * void __flush_dcache_icache(void *page)
> > */
> > _GLOBAL(__flush_dcache_icache)
> > +BEGIN_FTR_SECTION
> > + blr
> > +END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
> > /*
> > * Flush the data cache to memory
> > *
>
>
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] powerpc: move the testing of CPU_FTR_COHERENT_ICACHE into __flush_icache_range
From: Kevin Hao @ 2013-08-07 6:09 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc
In-Reply-To: <1375785310.12557.61.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 4327 bytes --]
On Tue, Aug 06, 2013 at 08:35:10PM +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2013-08-06 at 18:23 +0800, Kevin Hao wrote:
> > In function flush_icache_range(), we use cpu_has_feature() to test
> > the feature bit of CPU_FTR_COHERENT_ICACHE. But this seems not optimal
> > for two reasons:
> > a) For ppc32, the function __flush_icache_range() already do this
> > check with the macro END_FTR_SECTION_IFSET.
> > b) Compare with the cpu_has_feature(), the method of using macro
> > END_FTR_SECTION_IFSET will not introduce any runtime overhead.
>
> Nak.
>
> It adds the overhead of calling into a function :-)
>
> What about modifying cpu_has_feature to use jump labels ?
That's a great idea. I would like to gave it a try later.
>It might solve
> the problem of no runtime overhead ... however it might also be hard to
> keep the ability to remove the whole statement at compile time if the
> bit doesn't fit in the POSSIBLE mask... unless you find the right macro
> magic.
>
> In any case, I suspect the function call introduces more overhead than
> the bit test + conditional branch which will generally predict very
> well, so the patch as-is is probably a regression.
I don't think so. For the 64bit CPU which has a non-coherent icache,
there is no any effect introduced by this patch since (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
always yield true at compile time. But for the 64bit CPU which does have
the coherent icache, the following is the asm code before applying this patch:
c000000000023b4c: e9 22 86 68 ld r9,-31128(r2)
c000000000023b50: e9 29 00 00 ld r9,0(r9)
c000000000023b54: e9 29 00 10 ld r9,16(r9)
c000000000023b58: 79 2a 07 e1 clrldi. r10,r9,63
c000000000023b5c: 41 82 00 94 beq c000000000023bf0 <.handle_rt_signal64+0x670>
...
c000000000023bf0: 7f 23 cb 78 mr r3,r25
c000000000023bf4: 7f 64 db 78 mr r4,r27
c000000000023bf8: 48 7a 65 99 bl c0000000007ca190 <.__flush_icache_range>
After applying this patch, the following code is generated:
c000000000023b48: 7f 23 cb 78 mr r3,r25
c000000000023b4c: 7f 64 db 78 mr r4,r27
c000000000023b50: 48 7a 65 81 bl c0000000007ca0d0 <.flush_icache_range>
The run path for these two cases are:
before after
ld r9,-31128(r2) mr r3,r25
ld r9,0(r9) mr r4,r27
ld r9,16(r9) bl flush_icache_range
clrldi. r10,r9,63 blr
beq xxxx
So I don't think this will introduce more overhead than before.
On the contrary, I believe it yield less overhead than before.
Correct me if I am wrong.
>
> Did you measure ?
No. I don't have a access to 64bit CPU which has a coherent icache.
For a non-coherent icache 64bit CPU this patch will not cause any effect.
Thanks,
Kevin
>
> Ben.
>
>
> > Signed-off-by: Kevin Hao <haokexin@gmail.com>
> > ---
> > arch/powerpc/include/asm/cacheflush.h | 3 +--
> > arch/powerpc/kernel/misc_64.S | 4 +++-
> > 2 files changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/cacheflush.h b/arch/powerpc/include/asm/cacheflush.h
> > index b843e35..60b620d 100644
> > --- a/arch/powerpc/include/asm/cacheflush.h
> > +++ b/arch/powerpc/include/asm/cacheflush.h
> > @@ -35,8 +35,7 @@ extern void __flush_disable_L1(void);
> > extern void __flush_icache_range(unsigned long, unsigned long);
> > static inline void flush_icache_range(unsigned long start, unsigned long stop)
> > {
> > - if (!cpu_has_feature(CPU_FTR_COHERENT_ICACHE))
> > - __flush_icache_range(start, stop);
> > + __flush_icache_range(start, stop);
> > }
> >
> > extern void flush_icache_user_range(struct vm_area_struct *vma,
> > diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
> > index 6820e45..74d87f1 100644
> > --- a/arch/powerpc/kernel/misc_64.S
> > +++ b/arch/powerpc/kernel/misc_64.S
> > @@ -68,7 +68,9 @@ PPC64_CACHES:
> > */
> >
> > _KPROBE(__flush_icache_range)
> > -
> > +BEGIN_FTR_SECTION
> > + blr
> > +END_FTR_SECTION_IFSET(CPU_FTR_COHERENT_ICACHE)
> > /*
> > * Flush the data cache to memory
> > *
>
>
[-- Attachment #2: Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH v2] powerpc/eeh: powerpc/eeh: Fix undefined variable
From: Mike Qiu @ 2013-08-07 6:01 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mike Qiu, shangw
'pe_no' hasn't been defined, it should be an typo error,
it should be 'frozen_pe_no'.
Also '__func__' has missed in IODA_EEH_DBG(),
For safety reasons, use pr_info() directly, instead
of use IODA_EEH_DBG()
Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
---
arch/powerpc/platforms/powernv/eeh-ioda.c | 22 ++++++++--------------
1 file changed, 8 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
index 0cd1c4a..8bc19c8 100644
--- a/arch/powerpc/platforms/powernv/eeh-ioda.c
+++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
@@ -36,13 +36,6 @@
#include "powernv.h"
#include "pci.h"
-/* Debugging option */
-#ifdef IODA_EEH_DBG_ON
-#define IODA_EEH_DBG(args...) pr_info(args)
-#else
-#define IODA_EEH_DBG(args...)
-#endif
-
static char *hub_diag = NULL;
static int ioda_eeh_nb_init = 0;
@@ -823,17 +816,17 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
/* If OPAL API returns error, we needn't proceed */
if (rc != OPAL_SUCCESS) {
- IODA_EEH_DBG("%s: Invalid return value on "
- "PHB#%x (0x%lx) from opal_pci_next_error",
- __func__, hose->global_number, rc);
+ pr_info("%s: Invalid return value on "
+ "PHB#%x (0x%lx) from opal_pci_next_error",
+ __func__, hose->global_number, rc);
continue;
}
/* If the PHB doesn't have error, stop processing */
if (err_type == OPAL_EEH_NO_ERROR ||
severity == OPAL_EEH_SEV_NO_ERROR) {
- IODA_EEH_DBG("%s: No error found on PHB#%x\n",
- __func__, hose->global_number);
+ pr_info("%s: No error found on PHB#%x\n",
+ __func__, hose->global_number);
continue;
}
@@ -842,8 +835,9 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
* highest priority reported upon multiple errors on the
* specific PHB.
*/
- IODA_EEH_DBG("%s: Error (%d, %d, %d) on PHB#%x\n",
- err_type, severity, pe_no, hose->global_number);
+ pr_info("%s: Error (%d, %d, %d) on PHB#%x\n",
+ __func__, err_type, severity,
+ frozen_pe_no, hose->global_number);
switch (err_type) {
case OPAL_EEH_IOC_ERROR:
if (severity == OPAL_EEH_SEV_IOC_DEAD) {
--
1.8.2.1
^ permalink raw reply related
* Re: PCIE device errors after linux kernel upgrade
From: Leon Ravich @ 2013-08-07 5:41 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci@vger.kernel.org, linuxppc-dev
In-Reply-To: <CAPWoNkJtnE3ASH0AdgfAD-3soa13DyH-zZAyzWMg9K2=nCX87Q@mail.gmail.com>
>From comparison of pci printout from the two kernel ,
beside the EDAC errors I noticed other strange differences:
In 3.8.13 I got BAR 7 and BAR 8:
[ 39.017749] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0000000-0xdfffffff]
[ 39.024530] pci 0000:00:00.0: BAR 7: can't assign io (size 0x10000)
In 3.8.13 I am getting:
[ 38.931873] pci_bus 0000:01: busn_res: can not insert [bus 01-ff]
under [bus 00-01] (conflicts with (null) [bus 00-01])
On 6 August 2013 09:32, Leon Ravich <lravich@gmail.com> wrote:
> Thanks Bjorn.
>
> 1) If I understand it right this patch only removes the "pci
> 0000:00:00.0: ignoring class 0x0b2000 (doesn't
> match header type 01)" message , don't care about it , had it before .
>
> 2) regarding the comparing of printouts:
>
> kernel 3.8.13:
>
> [ 37.908846] pci_bus 0000:00: scanning bus
> [ 37.912870] pci 0000:00:00.0: [1957:0070] type 01 class 0x0b2000
> [ 37.918881] pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't
> match header type 01)
> [ 37.926640] pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x5c
> [ 37.933596] pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0xf0
> [ 37.940132] pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x78
> [ 37.946505] pci 0000:00:00.0: supports D1 D2
> [ 37.950779] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [ 37.957397] pci 0000:00:00.0: PME# disabled
> [ 37.961580] PCIE error(s) detected
> [ 37.964971] PCIE ERR_DR register: 0x00020000
> [ 37.969229] PCIE ERR_CAP_STAT register: 0x00000041
> [ 37.974008] PCIE ERR_CAP_R0 register: 0x00000800
> [ 37.978614] PCIE ERR_CAP_R1 register: 0x00000000
> [ 37.983218] PCIE ERR_CAP_R2 register: 0x00000000
> [ 37.987823] PCIE ERR_CAP_R3 register: 0x00000000
> [ 37.992448] PCIE error(s) detected
> [ 37.995841] PCIE ERR_DR register: 0x00020000
> [ 38.000098] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.004877] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.009482] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.014087] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.018692] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.023312] PCIE error(s) detected
> [ 38.026704] PCIE ERR_DR register: 0x00020000
> [ 38.030961] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.035740] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.040345] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.044950] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.049554] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.054180] PCIE error(s) detected
> [ 38.057573] PCIE ERR_DR register: 0x00020000
> [ 38.061831] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.066609] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.071214] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.075819] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.080424] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.085046] PCIE error(s) detected
> [ 38.088438] PCIE ERR_DR register: 0x00020000
> [ 38.092696] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.097474] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.102079] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.106684] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.111289] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.115909] PCIE error(s) detected
> [ 38.119301] PCIE ERR_DR register: 0x00020000
> [ 38.123559] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.128337] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.132942] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.137547] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.142152] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.146773] PCIE error(s) detected
> [ 38.150164] PCIE ERR_DR register: 0x00020000
> [ 38.154423] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.159201] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.163806] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.168410] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.173015] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.177635] PCIE error(s) detected
> [ 38.181028] PCIE ERR_DR register: 0x00020000
> [ 38.185286] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.190066] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.194670] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.199275] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.203880] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.208504] PCIE error(s) detected
> [ 38.211897] PCIE ERR_DR register: 0x00020000
> [ 38.216156] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.220935] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.225540] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.230144] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.234749] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.239395] PCIE error(s) detected
> [ 38.242788] PCIE ERR_DR register: 0x00020000
> [ 38.247046] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.251825] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.256430] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.261034] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.265639] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.270268] PCIE error(s) detected
> [ 38.273660] PCIE ERR_DR register: 0x00020000
> [ 38.277918] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.282697] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.287302] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.291906] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.296511] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.301134] PCIE error(s) detected
> [ 38.304526] PCIE ERR_DR register: 0x00020000
> [ 38.308784] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.313563] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.318168] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.322772] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.327377] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.331999] PCIE error(s) detected
> [ 38.335390] PCIE ERR_DR register: 0x00020000
> [ 38.339648] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.344427] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.349031] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.353636] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.358241] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.362862] PCIE error(s) detected
> [ 38.366255] PCIE ERR_DR register: 0x00020000
> [ 38.370512] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.375291] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.379896] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.384501] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.389106] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.393728] PCIE error(s) detected
> [ 38.397121] PCIE ERR_DR register: 0x00020000
> [ 38.401379] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.406158] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.410763] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.415367] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.419972] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.424613] PCIE error(s) detected
> [ 38.428007] PCIE ERR_DR register: 0x00020000
> [ 38.432264] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.437043] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.441648] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.446253] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.450857] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.455483] PCIE error(s) detected
> [ 38.458875] PCIE ERR_DR register: 0x00020000
> [ 38.463133] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.467911] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.472516] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.477121] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.481726] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.486351] PCIE error(s) detected
> [ 38.489743] PCIE ERR_DR register: 0x00020000
> [ 38.494001] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.498780] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.503385] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.507989] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.512594] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.517212] PCIE error(s) detected
> [ 38.520603] PCIE ERR_DR register: 0x00020000
> [ 38.524860] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.529639] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.534244] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.538849] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.543453] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.548069] PCIE error(s) detected
> [ 38.551461] PCIE ERR_DR register: 0x00020000
> [ 38.555719] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.560497] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.565102] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.569707] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.574312] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.578928] PCIE error(s) detected
> [ 38.582318] PCIE ERR_DR register: 0x00020000
> [ 38.586576] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.591354] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.595959] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.600564] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.605169] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.609784] PCIE error(s) detected
> [ 38.613175] PCIE ERR_DR register: 0x00020000
> [ 38.617433] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.622211] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.626816] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.631421] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.636026] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.640658] PCIE error(s) detected
> [ 38.644050] PCIE ERR_DR register: 0x00020000
> [ 38.648309] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.653088] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.657692] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.662297] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.666902] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.671522] PCIE error(s) detected
> [ 38.674914] PCIE ERR_DR register: 0x00020000
> [ 38.679172] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.683951] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.688556] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.693161] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.697766] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.702386] PCIE error(s) detected
> [ 38.705777] PCIE ERR_DR register: 0x00020000
> [ 38.710034] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.714813] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.719418] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.724023] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.728628] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.733244] PCIE error(s) detected
> [ 38.736636] PCIE ERR_DR register: 0x00020000
> [ 38.740895] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.745673] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.750278] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.754883] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.759488] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.764103] PCIE error(s) detected
> [ 38.767494] PCIE ERR_DR register: 0x00020000
> [ 38.771752] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.776530] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.781135] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.785740] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.790344] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.794984] PCIE error(s) detected
> [ 38.798377] PCIE ERR_DR register: 0x00020000
> [ 38.802635] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.807414] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.812019] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.816624] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.821229] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.825848] PCIE error(s) detected
> [ 38.829239] PCIE ERR_DR register: 0x00020000
> [ 38.833496] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.838275] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.842880] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.847485] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.852090] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.856712] PCIE error(s) detected
> [ 38.860103] PCIE ERR_DR register: 0x00020000
> [ 38.864361] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.869139] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.873744] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.878349] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.882954] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.887574] PCIE error(s) detected
> [ 38.890966] PCIE ERR_DR register: 0x00020000
> [ 38.895223] PCIE ERR_CAP_STAT register: 0x00000041
> [ 38.900002] PCIE ERR_CAP_R0 register: 0x00000800
> [ 38.904607] PCIE ERR_CAP_R1 register: 0x00000000
> [ 38.909212] PCIE ERR_CAP_R2 register: 0x00000000
> [ 38.913817] PCIE ERR_CAP_R3 register: 0x00000000
> [ 38.918446] pci 0000:00:00.0: scanning [bus 01-01] behind bridge, pass 0
> [ 38.925142] pci 0000:00:00.0: scanning [bus 00-00] behind bridge, pass 1
> [ 38.931873] pci_bus 0000:01: busn_res: can not insert [bus 01-ff]
> under [bus 00-01] (conflicts with (null) [bus 00-01])
> [ 38.942654] pci_bus 0000:01: scanning bus
> [ 38.946687] pci 0000:01:00.0: [1234:0002] type 00 class 0xff0000
> [ 38.952697] pci 0000:01:00.0: reg 10: [mem 0x00000000-0x000fffff]
> [ 38.958801] pci 0000:01:00.0: reg 14: [mem 0x00000000-0x0007ffff]
> [ 38.964891] pci 0000:01:00.0: reg 18: [mem 0x00000000-0x0007ffff]
> [ 38.971017] pci 0000:01:00.0: calling pcibios_fixup_resources+0x0/0xf0
> [ 38.977605] pci_bus 0000:01: fixups for bus
> [ 38.981782] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
> [ 38.987012] pci 0000:00:00.0: bridge window [io 0x0000-0x0fff]
> [ 38.993098] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
> [ 38.999970] pci_bus 0000:01: bus scan returning with max=01
> [ 39.005537] pci_bus 0000:01: busn_res: [bus 01-ff] end is updated to 01
> [ 39.012158] pci_bus 0000:00: bus scan returning with max=01
> [ 39.017749] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0000000-0xdfffffff]
> [ 39.024530] pci 0000:00:00.0: BAR 7: can't assign io (size 0x10000)
> [ 39.030801] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff]
> [ 39.037596] pci 0000:01:00.0: BAR 0: set to [mem
> 0xc0000000-0xc00fffff] (PCI address [0xc0000000-0xc00fffff])
> [ 39.047511] pci 0000:01:00.0: BAR 1: assigned [mem 0xc0100000-0xc017ffff]
> [ 39.054293] pci 0000:01:00.0: BAR 1: set to [mem
> 0xc0100000-0xc017ffff] (PCI address [0xc0100000-0xc017ffff])
> [ 39.064204] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0180000-0xc01fffff]
> [ 39.070997] pci 0000:01:00.0: BAR 2: set to [mem
> 0xc0180000-0xc01fffff] (PCI address [0xc0180000-0xc01fffff])
> [ 39.080910] pci 0000:00:00.0: PCI bridge to [bus 01]
> [ 39.085866] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
> [ 39.092662] pci 0000:00:00.0: enabling bus mastering
>
>
>
>
> kernel 2.6.32
>
> [ 49.665070] PCI: Scanning bus 0000:00
> [ 49.668744] pci 0000:00:00.0: found [1957:0070] class 000b20 header type 01
> [ 49.675708] pci 0000:00:00.0: ignoring class b20 (doesn't match
> header type 01)
> [ 49.683028] pci 0000:00:00.0: calling fixup_hide_host_resource_fsl+0x0/0x5c
> [ 49.689991] pci 0000:00:00.0: calling pcibios_fixup_resources+0x0/0xd0
> [ 49.696525] pci 0000:00:00.0: calling quirk_fsl_pcie_header+0x0/0x64
> [ 49.702885] pci 0000:00:00.0: calling quirk_resource_alignment+0x0/0x1d4
> [ 49.709583] pci 0000:00:00.0: supports D1 D2
> [ 49.713851] pci 0000:00:00.0: PME# supported from D0 D1 D2 D3hot D3cold
> [ 49.720457] pci 0000:00:00.0: PME# disabled
> [ 49.724657] pci 0000:00:00.0: scanning behind bridge, config 010100, pass 0
> [ 49.731611] pci 0000:00:00.0: scanning behind bridge, config 000000, pass 1
> [ 49.738576] PCI: Scanning bus 0000:01
> [ 49.742256] pci 0000:01:00.0: found [1234:0002] class 00ff00 header type 00
> [ 49.749224] pci 0000:01:00.0: reg 10 32bit mmio: [0x000000-0x0fffff]
> [ 49.755584] pci 0000:01:00.0: reg 14 32bit mmio: [0x000000-0x07ffff]
> [ 49.761932] pci 0000:01:00.0: reg 18 32bit mmio: [0x000000-0x07ffff]
> [ 49.768302] pci 0000:01:00.0: calling pcibios_fixup_resources+0x0/0xd0
> [ 49.774830] pci 0000:01:00.0: calling quirk_resource_alignment+0x0/0x1d4
> [ 49.781566] PCI: Fixups for bus 0000:01
> [ 49.785402] pci 0000:00:00.0: bridge io port: [0x00-0xfff]
> [ 49.790879] pci 0000:00:00.0: bridge 32bit mmio: [0xc0000000-0xdfffffff]
> [ 49.797627] PCI: Bus scan for 0000:01 returning with max=01
> [ 49.803200] PCI: Bus scan for 0000:00 returning with max=01
> [ 49.808777] pci 0000:01:00.0: BAR 0: got res
> [0xc0000000-0xc00fffff] bus [0xc0000000-0xc00fffff] flags 0x20020200
> [ 49.819041] pci 0000:01:00.0: BAR 0: moved to bus
> [0xc0000000-0xc00fffff] flags 0x20200
> [ 49.827043] pci 0000:01:00.0: BAR 1: got res
> [0xc0100000-0xc017ffff] bus [0xc0100000-0xc017ffff] flags 0x20020200
> [ 49.837303] pci 0000:01:00.0: BAR 1: moved to bus
> [0xc0100000-0xc017ffff] flags 0x20200
> [ 49.845306] pci 0000:01:00.0: BAR 2: got res
> [0xc0180000-0xc01fffff] bus [0xc0180000-0xc01fffff] flags 0x20020200
> [ 49.855566] pci 0000:01:00.0: BAR 2: moved to bus
> [0xc0180000-0xc01fffff] flags 0x20200
> [ 49.863568] pci 0000:00:00.0: PCI bridge, secondary bus 0000:01
> [ 49.869477] pci 0000:00:00.0: IO window: disabled
> [ 49.874352] pci 0000:00:00.0: MEM window: 0xc0000000-0xc01fffff
> [ 49.880436] pci 0000:00:00.0: PREFETCH window: disabled
>
>
>
> On 5 August 2013 18:38, Bjorn Helgaas <bhelgaas@google.com> wrote:
>> [+cc linuxppc-dev]
>>
>> On Mon, Aug 5, 2013 at 5:17 AM, Leon Ravich <lravich@gmail.com> wrote:
>>> Hi all ,
>>> I am trying to upgrade ours embedded device (freescale powerPC P2020 cpu)
>>> linux kernel , till now we used 2.6.32 I am trying to upgrade to 3.8.13 .
>>> I took the source from freescale git:
>>> git://git.freescale.com/ppc/sdk/linux.git
>>>
>>> on our embedded device we have an FPGA connected through PCIE .
>>>
>>> on each boot we loading the rbf design to the FPGA and the rescan pci bus to let
>>> kernel detect it .
>>>
>>> during the rescan I getting error messages:
>>> genirq: Setting trigger mode 0 for irq 27 failed
>>> (mpc8xxx_irq_set_type+0x0/0xec)
>>> [ 22.060898] genirq: Setting trigger mode 0 for irq 28 failed
>>> (mpc8xxx_irq_set_type+0x0/0xec)
>>> [ 22.069461] genirq: Setting trigger mode 0 for irq 31 failed
>>> (mpc8xxx_irq_set_type+0x0/0xec)
>>> [ 22.078010] genirq: Setting trigger mode 0 for irq 32 failed
>>> (mpc8xxx_irq_set_type+0x0/0xec)
>>> [ 22.086576] genirq: Setting trigger mode 0 for irq 33 failed
>>> (mpc8xxx_irq_set_type+0x0/0xec)
>>> [ 22.095143] genirq: Setting trigger mode 0 for irq 37 failed
>>> (mpc8xxx_irq_set_type+0x0/0xec)
>>> [ 22.103715] genirq: Setting trigger mode 0 for irq 38 failed
>>> (mpc8xxx_irq_set_type+0x0/0xec)
>>> [ 22.112282] genirq: Setting trigger mode 0 for irq 39 failed
>>> (mpc8xxx_irq_set_type+0x0/0xec)
>>
>> Hmm, I don't know much about IRQ issues.
>>
>>> [ 37.945785] pci 0000:00:00.0: ignoring class 0x0b2000 (doesn't
>>> match header type 01)
>>
>> There's a recent patch related to this:
>> http://lkml.kernel.org/r/1374823418-1550-1-git-send-email-Chunhe.Lan@freescale.com
>>
>>> [ 37.953640] PCIE error(s) detected
>>> [ 37.953858] pci 0000:00:00.0: PCI bridge to [bus 01-ff]
>>> [ 37.953988] pci 0000:00:00.0: BAR 8: assigned [mem 0xc0000000-0xdfffffff]
>>> [ 37.953994] pci 0000:00:00.0: BAR 7: can't assign io (size 0x10000)
>>> [ 37.954000] pci 0000:01:00.0: BAR 0: assigned [mem 0xc0000000-0xc00fffff]
>>> [ 37.954013] pci 0000:01:00.0: BAR 1: assigned [mem 0xc0100000-0xc017ffff]
>>> [ 37.954025] pci 0000:01:00.0: BAR 2: assigned [mem 0xc0180000-0xc01fffff]
>>> [ 37.954036] pci 0000:00:00.0: PCI bridge to [bus 01]
>>> [ 37.954041] pci 0000:00:00.0: bridge window [mem 0xc0000000-0xdfffffff]
>>> [ 38.007354] PCIE ERR_DR register: 0x80020000
>>> [ 38.011613] PCIE ERR_CAP_STAT register: 0x00000041
>>> [ 38.016392] PCIE ERR_CAP_R0 register: 0x00000800
>>> [ 38.020997] PCIE ERR_CAP_R1 register: 0x00000000
>>> [ 38.025602] PCIE ERR_CAP_R2 register: 0x00000000
>>> [ 38.030207] PCIE ERR_CAP_R3 register: 0x00000000
>>>
>>>
>>> and after a few minutes I linux reboot it self,
>>>
>>>
>>> where can I start debugging it??
>>
>> I'd start by applying the header quirk patch above, then comparing the
>> complete console log (boot with "ignore_loglevel") from 2.6.32 and
>> 3.8.13.
>>
>> Bjorn
>
>
>
> --
> Leonid Ravich
--
Leonid Ravich
^ permalink raw reply
* Re: [PATCH] powerpc/eeh: Fix undefined variable
From: Mike Qiu @ 2013-08-07 5:37 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20130807052548.GA6070@shangw.(null)>
于 2013/8/7 13:25, Gavin Shan 写道:
> On Wed, Aug 07, 2013 at 03:11:24PM +1000, Michael Ellerman wrote:
>> On Tue, Aug 06, 2013 at 10:24:46PM -0400, Mike Qiu wrote:
>>> 'pe_no' hasn't been defined, it should be an typo error,
>>> it should be 'frozen_pe_no'.
>>>
>>> Also '__func__' should be added to IODA_EEH_DBG(),
>>>
>>> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
>>> ---
>>> arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++-
>>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
>>> index 0cd1c4a..a49bee7 100644
>>> --- a/arch/powerpc/platforms/powernv/eeh-ioda.c
>>> +++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
>>> @@ -843,7 +843,8 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
>>> * specific PHB.
>>> */
>>> IODA_EEH_DBG("%s: Error (%d, %d, %d) on PHB#%x\n",
>>> - err_type, severity, pe_no, hose->global_number);
>>> + __func__, err_type, severity,
>>> + frozen_pe_no, hose->global_number);
>> Why is it using a custom macro? If you use pr_devel() or similar you
>> avoid these bugs, because the argument list is always expanded.
>>
> The custom macro at least can save some CPU cycles, but that's not
> safe as you mentioned. It's resonable to use pr_devel() here.
>
> Mike, could you help to replace IODA_EEH_DBG() with pr_devel() as
> Michael suggested?
OK, I will change the patch in V2
Thanks
Mike
>
> Thanks,
> Gavin
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
>
^ permalink raw reply
* Re: [PATCH 00/11] Add compression support to pstore
From: Tony Luck @ 2013-08-07 5:35 UTC (permalink / raw)
To: Aruna Balakrishnaiah
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
linux-kernel@vger.kernel.org, keescook@chromium.org
In-Reply-To: <5201D777.8060303@linux.vnet.ibm.com>
On Tue, Aug 6, 2013 at 10:13 PM, Aruna Balakrishnaiah
<aruna@linux.vnet.ibm.com> wrote:
> How is it with erst and efivars?
ERST is at the whim of the BIOS writer (the ACPI standard doesn't provide any
suggestions on record sizes). My systems support ~6K record size.
efivars has, IIRC, a 1k limit coded in the Linux back end.
-Tony
^ permalink raw reply
* Re: [PATCH] powerpc/eeh: Fix undefined variable
From: Gavin Shan @ 2013-08-07 5:25 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Mike Qiu, shangw
In-Reply-To: <20130807051124.GA19998@concordia>
On Wed, Aug 07, 2013 at 03:11:24PM +1000, Michael Ellerman wrote:
>On Tue, Aug 06, 2013 at 10:24:46PM -0400, Mike Qiu wrote:
>> 'pe_no' hasn't been defined, it should be an typo error,
>> it should be 'frozen_pe_no'.
>>
>> Also '__func__' should be added to IODA_EEH_DBG(),
>>
>> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
>> ---
>> arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
>> index 0cd1c4a..a49bee7 100644
>> --- a/arch/powerpc/platforms/powernv/eeh-ioda.c
>> +++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
>> @@ -843,7 +843,8 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
>> * specific PHB.
>> */
>> IODA_EEH_DBG("%s: Error (%d, %d, %d) on PHB#%x\n",
>> - err_type, severity, pe_no, hose->global_number);
>> + __func__, err_type, severity,
>> + frozen_pe_no, hose->global_number);
>
>Why is it using a custom macro? If you use pr_devel() or similar you
>avoid these bugs, because the argument list is always expanded.
>
The custom macro at least can save some CPU cycles, but that's not
safe as you mentioned. It's resonable to use pr_devel() here.
Mike, could you help to replace IODA_EEH_DBG() with pr_devel() as
Michael suggested?
Thanks,
Gavin
^ permalink raw reply
* Re: [PATCH 63/63] powerpc: Add pseries_le_defconfig
From: Michael Ellerman @ 2013-08-07 5:16 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, Paul Mackerras, Anton Blanchard
In-Reply-To: <2419.1375831860@ale.ozlabs.ibm.com>
On Wed, Aug 07, 2013 at 09:31:00AM +1000, Michael Neuling wrote:
> Anton Blanchard <anton@samba.org> wrote:
>
> > This is the pseries_defconfig with CONFIG_CPU_LITTLE_ENDIAN enabled
> > and CONFIG_VIRTUALIZATION disabled (required until we fix some
> > endian issues in KVM).
>
> The CONFIG_VIRTUALIZATION disabling should be done in the Kconfig not
> here.
>
> I'm not that keen on another defconfig. benh is already talking about
> having a powernv defconfig. I'm worried we are going to fragment the
> defconfigs. If you want something special like LE, then change the
> default one.
I disagree. defconfigs are great because they're easy to add to kisskb
or other auto builders, making automated build testing easier.
In fact because the defconfigs are pretty much the only thing that
people build test, if you stray too far from them you are almost
guaranteed to find breakage. For example the UP build was broken for
months because we didn't have a defconfig for it.
cheers
^ permalink raw reply
* Re: [PATCH 00/11] Add compression support to pstore
From: Aruna Balakrishnaiah @ 2013-08-07 5:13 UTC (permalink / raw)
To: Tony Luck
Cc: linuxppc-dev@ozlabs.org, paulus@samba.org,
linux-kernel@vger.kernel.org, keescook@chromium.org
In-Reply-To: <CA+8MBbJS0Dymn4OABi-rW9M5Bw-ZZ6DaEjQOW-oki+4ge4BDtg@mail.gmail.com>
Hi Tony,
On Wednesday 07 August 2013 08:55 AM, Tony Luck wrote:
> On Tue, Aug 6, 2013 at 6:58 PM, Aruna Balakrishnaiah
> <aruna@linux.vnet.ibm.com> wrote:
>> The patch looks right. I will clean it up. Does the issue still persist
>> after this?
> Things seem to be working - but testing has hardly been extensive (just
> a couple of forced panics).
>
> I do have one other question. In this code:
>
>>> if (compressed && (type == PSTORE_TYPE_DMESG)) {
>>> big_buf_sz = (psinfo->bufsize * 100) / 45;
> Where does the magic multiply by 1.45 come from? Is that always enough
> for the decompression of "dmesg" type data to succeed?
I had this in my cover letter of the series, posting the same from it
Writing to persistent store
----------------------------
Compression will reduce the size of oops/panic report to atmost 45% of its
original size. (Based on experiments done while providing compression support
to nvram by Jim keniston).
Hence buffer of size ( (100/45 approx 2.22) *<registered_buffer> is allocated).
The compression parameters selected based on some experiments:
compression_level = 6, window_bits = 12, memory_level = 4 which achieved a
significant compression of 12 % of uncompressed buffer size tried upto 36k.
Data is compressed from the bigger buffer to registered buffer which is
returned to backends.
Pstore will indicate that with a flag 'compressed' which is passed to backends.
Using this flag, backends will add a flag in their header to indicate the data
is compressed or not while writing to persistent store.
The significant compression that I have mentioned had repeated occurrences in the
text. When I tried with plain text I saw compression of around 45% with compression
parameters I have used.
If the record size is fixed across all the backends then it would be easy to come
up with a pre defined set of compression parameters as well as the buffer size of
compressed/decompressed data based on experiments. In power as of now, the maximum size
of the record is 4k. So compression support on power was provided with multiply (100/45)
considering the maximum record size to be 4k.
How is it with erst and efivars?
- Aruna
> -Tony
>
^ permalink raw reply
* Re: [PATCH] powerpc/eeh: Fix undefined variable
From: Michael Ellerman @ 2013-08-07 5:11 UTC (permalink / raw)
To: Mike Qiu; +Cc: linuxppc-dev, shangw
In-Reply-To: <1375842286-26521-1-git-send-email-qiudayu@linux.vnet.ibm.com>
On Tue, Aug 06, 2013 at 10:24:46PM -0400, Mike Qiu wrote:
> 'pe_no' hasn't been defined, it should be an typo error,
> it should be 'frozen_pe_no'.
>
> Also '__func__' should be added to IODA_EEH_DBG(),
>
> Signed-off-by: Mike Qiu <qiudayu@linux.vnet.ibm.com>
> ---
> arch/powerpc/platforms/powernv/eeh-ioda.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/platforms/powernv/eeh-ioda.c b/arch/powerpc/platforms/powernv/eeh-ioda.c
> index 0cd1c4a..a49bee7 100644
> --- a/arch/powerpc/platforms/powernv/eeh-ioda.c
> +++ b/arch/powerpc/platforms/powernv/eeh-ioda.c
> @@ -843,7 +843,8 @@ static int ioda_eeh_next_error(struct eeh_pe **pe)
> * specific PHB.
> */
> IODA_EEH_DBG("%s: Error (%d, %d, %d) on PHB#%x\n",
> - err_type, severity, pe_no, hose->global_number);
> + __func__, err_type, severity,
> + frozen_pe_no, hose->global_number);
Why is it using a custom macro? If you use pr_devel() or similar you
avoid these bugs, because the argument list is always expanded.
cheers
^ permalink raw reply
* Re: [PATCH 48/63] powerpc/kvm/book3s_hv: Add little endian guest support
From: Paul Mackerras @ 2013-08-07 4:24 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1375804940-22050-49-git-send-email-anton@samba.org>
On Wed, Aug 07, 2013 at 02:02:05AM +1000, Anton Blanchard wrote:
> Add support for the H_SET_MODE hcall so we can select the
> endianness of our exceptions.
>
> We create a guest MSR from scratch when delivering exceptions in
> a few places and instead of extracting the LPCR[ILE] and inserting
> it into MSR_LE each time simply create a new variable intr_msr which
> contains the entire MSR to use.
>
> Signed-off-by: Anton Blanchard <anton@samba.org>
Acked-by: Paul Mackerras <paulus@samba.org>
^ permalink raw reply
* Re: [PATCH 36/63] powerpc: Book 3S MMU little endian support
From: Paul Mackerras @ 2013-08-07 4:20 UTC (permalink / raw)
To: Anton Blanchard; +Cc: linuxppc-dev
In-Reply-To: <1375804940-22050-37-git-send-email-anton@samba.org>
On Wed, Aug 07, 2013 at 02:01:53AM +1000, Anton Blanchard wrote:
> +#ifdef __BIG_ENDIAN__
> #define HPTE_LOCK_BIT 3
> +#else
> +#define HPTE_LOCK_BIT (63-3)
> +#endif
Are you deliberately using a different bit here? AFAICS you are using
0x20 in the 7th byte as the lock bit for LE, whereas we use 0x08 in
that byte on BE. Both are software-use bits, so it will still work,
but is there a rationale for the change? Or did you mean (56+3)
rather than (63-3)?
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Convert out of line __arch_hweight to inline
From: Anshuman Khandual @ 2013-08-07 4:02 UTC (permalink / raw)
To: Madhavan Srinivasan; +Cc: linuxppc-dev, anton
In-Reply-To: <1375788627-22281-1-git-send-email-maddy@linux.vnet.ibm.com>
>
> obj-$(CONFIG_PPC64) += copypage_64.o copyuser_64.o \
> memcpy_64.o usercopy_64.o mem_64.o string.o \
> - checksum_wrappers_64.o hweight_64.o \
> + checksum_wrappers_64.o \
> copyuser_power7.o string_64.o copypage_power7.o \
> memcpy_power7.o
> obj-$(CONFIG_PPC_EMULATE_SSTEP) += sstep.o ldstfp.o
>
As you have moved all the code from hweight_64.S file and removed it from the
compilation list in the Makefile, you need to delete the file from the directory as well.
^ permalink raw reply
* RE: PCIE device errors after linux kernel upgrade
From: Zang Roy-R61911 @ 2013-08-07 3:35 UTC (permalink / raw)
To: Leon Ravich, Johannes Thumshirn
Cc: Bjorn Helgaas, linux-pci@vger.kernel.org, linuxppc-dev
In-Reply-To: <CAPWoNkKo6Cfg0Hr2QYBXVnUrC-UQwES65UUHfSvR3nBvZrfFoA@mail.gmail.com>
> -----Original Message-----
> From: Linuxppc-dev [mailto:linuxppc-dev-bounces+tie-
> fei.zang=3Dfreescale.com@lists.ozlabs.org] On Behalf Of Leon Ravich
> Sent: Tuesday, August 06, 2013 3:26 PM
> To: Johannes Thumshirn
> Cc: Bjorn Helgaas; linux-pci@vger.kernel.org; linuxppc-dev
> Subject: Re: PCIE device errors after linux kernel upgrade
>=20
> Hi Johannes
> no panic just reboot.
> it is not the first read, it takes few minutes of work with pcie to
> reboot.
You may need to check the error code in EDAC driver as Johannes suggested.
Roy
^ 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