headers
David Woodhouse | 1 Aug 2009 09:54
Favicon

Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway

On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> > On an iMac G5, the b43 driver is failing to initialise because trying to
> > set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> > in the machine anyway:
> > 	https://bugzilla.redhat.com/show_bug.cgi?id=514787
> > 
> > We should probably let it succeed if the available RAM in the system
> > doesn't exceed the requested limit.
> > 
> > Signed-off-by: David Woodhouse <David.Woodhouse <at> intel.com>
> 
> Also, isn't our iommu code smart enough to clamp allocations to the DMA
> mask nowadays ? In that case, we could probably just force iommu on
> always...

We're not using the IOMMU on this box:

PowerMac motherboard: iMac G5
DART: table not allocated, using direct DMA

--

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse <at> intel.com                              Intel Corporation
Permalink | Reply | 0 comments |
headers
Benjamin Herrenschmidt | 1 Aug 2009 10:00

Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway

On Sat, 2009-08-01 at 08:54 +0100, David Woodhouse wrote:
> On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote:
> > On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> > > On an iMac G5, the b43 driver is failing to initialise because trying to
> > > set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> > > in the machine anyway:
> > > 	https://bugzilla.redhat.com/show_bug.cgi?id=514787
> > > 
> > > We should probably let it succeed if the available RAM in the system
> > > doesn't exceed the requested limit.
> > > 
> > > Signed-off-by: David Woodhouse <David.Woodhouse <at> intel.com>
> > 
> > Also, isn't our iommu code smart enough to clamp allocations to the DMA
> > mask nowadays ? In that case, we could probably just force iommu on
> > always...
> 
> We're not using the IOMMU on this box:
> 
> PowerMac motherboard: iMac G5
> DART: table not allocated, using direct DMA

I know, I was suggesting we do :-)

Cheers,
Ben.
Permalink | Reply | 0 comments |
headers
Julia Lawall | 1 Aug 2009 10:52
Picon
Favicon

[PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree

From: Julia Lawall <julia <at> diku.dk>

Error handling code following a kzalloc should free the allocated data.

The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
 <at> r exists <at> 
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
 <at>  <at> 

x <at> p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
(
x->f1 = E
|
 (x->f1 == NULL || ...)
|
 f(...,x->f1,...)
)
...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Julia Lawall | 1 Aug 2009 10:53
Picon
Favicon

[PATCH 2/10] arch/powerpc: introduce missing kfree

From: Julia Lawall <julia <at> diku.dk>

Error handling code following a kzalloc should free the allocated data.

The semantic match that finds the problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)

// <smpl>
 <at> r exists <at> 
local idexpression x;
statement S;
expression E;
identifier f,f1,l;
position p1,p2;
expression *ptr != NULL;
 <at>  <at> 

x <at> p1 = \(kmalloc\|kzalloc\|kcalloc\)(...);
...
if (x == NULL) S
<... when != x
     when != if (...) { <+...x...+> }
(
x->f1 = E
|
 (x->f1 == NULL || ...)
|
 f(...,x->f1,...)
)
...>
(Continue reading)

Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Aug 2009 11:00
Favicon

Re: [PATCH] Stop pci_set_dma_mask() from failing when RAM doesn't exceed the mask anyway

On Sat, 2009-08-01 at 18:00 +1000, Benjamin Herrenschmidt wrote:
> On Sat, 2009-08-01 at 08:54 +0100, David Woodhouse wrote:
> > On Sat, 2009-08-01 at 08:25 +1000, Benjamin Herrenschmidt wrote:
> > > On Fri, 2009-07-31 at 20:41 +0100, David Woodhouse wrote:
> > > > On an iMac G5, the b43 driver is failing to initialise because trying to
> > > > set the dma mask to 30-bit fails. Even though there's only 512MiB of RAM
> > > > in the machine anyway:
> > > > 	https://bugzilla.redhat.com/show_bug.cgi?id=514787
> > > > 
> > > > We should probably let it succeed if the available RAM in the system
> > > > doesn't exceed the requested limit.
> > > > 
> > > > Signed-off-by: David Woodhouse <David.Woodhouse <at> intel.com>
> > > 
> > > Also, isn't our iommu code smart enough to clamp allocations to the DMA
> > > mask nowadays ? In that case, we could probably just force iommu on
> > > always...
> > 
> > We're not using the IOMMU on this box:
> > 
> > PowerMac motherboard: iMac G5
> > DART: table not allocated, using direct DMA
> 
> I know, I was suggesting we do :-)

I'm not sure. Losing 16MiB on a machine which only has 512MiB anyway
doesn't seem ideal, and we'll want to make the no-iommu code DTRT
_anyway_, surely?

So we might as well let the DART keep its existing logic (which is only
(Continue reading)

Permalink | Reply | 0 comments |
headers
Timur Tabi | 1 Aug 2009 14:25
Favicon

Re: [PATCH 1/10] arch/powerpc/sysdev/qe_lib: introduce missing kfree

On Sat, Aug 1, 2009 at 3:52 AM, Julia Lawall<julia <at> diku.dk> wrote:
> From: Julia Lawall <julia <at> diku.dk>
>
> Error handling code following a kzalloc should free the allocated data.
>

...

>
> Signed-off-by: Julia Lawall <julia <at> diku.dk>
> ---
>  arch/powerpc/sysdev/qe_lib/qe_ic.c  |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)

Acked-by: Timur Tabi <timur <at> freescale.com>

--

-- 
Timur Tabi
Linux kernel developer at Freescale
Permalink | Reply | 0 comments |
headers
David Woodhouse | 1 Aug 2009 15:29
Favicon

[PATCH] Fix perfctr oops on ppc32

This seems to be the reason why the Fedora rawhide 2.6.31-rc kernel
doesn't boot. With some CPUs, cur_cpu_spec->oprofile_cpu_type can be
NULL -- which makes strcmp() unhappy.

Signed-off-by: David Woodhouse <David.Woodhouse <at> intel.com>
---
At first glance, it looks like there are a bunch of other places which
use cur_cpu_spec->oprofile_cpu_type without first checking if it's
non-NULL, but maybe those are all 64-bit and all 64-bit cpu types have
it set?

diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/powerpc/kernel/mpc7450-pmu.c
index 75ff47f..ea383c1 100644
--- a/arch/powerpc/kernel/mpc7450-pmu.c
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
 <at>  <at>  -408,7 +408,8  <at>  <at>  struct power_pmu mpc7450_pmu = {

 static int init_mpc7450_pmu(void)
 {
-	if (strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
+	if (cur_cpu_spec->oprofile_cpu_type &&
+	    strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
 		return -ENODEV;

 	return register_power_pmu(&mpc7450_pmu);

--

-- 
David Woodhouse                            Open Source Technology Centre
David.Woodhouse <at> intel.com                              Intel Corporation
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linas Vepstas | 2 Aug 2009 00:40
Picon
Gravatar

Re: [PATCH 1/3] Support for PCI Express reset type

Hi Andi,

2009/7/31 Andi Kleen <andi <at> firstfloor.org>:
> Mike Mason <mmlnx <at> us.ibm.com> writes:
>>
>> These patches supersede the previously submitted patch that
>> implemented a fundamental reset bit field.
>>
>> Please review and let me know of any concerns.
>
> Any plans to implement that for x86 too? Right now it seems to be a PPC
> specific hack.

I've found the PCIE chipsepc somewhat daunting, but was under the
impression that much if not most of what was needed was specified
there.

See, for example:
    Documentation/PCI/pcieaer-howto.txt

which states:
|||   The PCI Express Advanced Error Reporting Driver Guide HOWTO
|||                T. Long Nguyen  <tom.l.nguyen <at> intel.com>
|||                Yanmin Zhang    <yanmin.zhang <at> intel.com>
|||                                07/29/2006
[..]
||| The PCI Express AER driver provides the infrastructure to support PCI
||| Express Advanced Error Reporting capability. The PCI Express AER
||| driver provides three basic functions:
|||
(Continue reading)

Permalink | Reply | 0 comments |
headers
Linas Vepstas | 2 Aug 2009 00:43
Picon
Gravatar

Re: [PATCH 1/3] Support for PCI Express reset type

2009/7/30 Mike Mason <mmlnx <at> us.ibm.com>:
> This is the first of three patches that implement a bit field that PCI
> Express device drivers can use to indicate they need a fundamental reset
> during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot reset"
> during recovery of a PCI Express device.  We've found a case where the
> device needs a "fundamental reset" to recover properly.  The current PCI
> error recovery and EEH frameworks do not support this distinction.
>
> The attached patch (courtesy of Richard Lary) adds a bit field to pci_dev
> that indicates whether the device requires a fundamental reset during
> recovery.
>
> These patches supersede the previously submitted patch that implemented a
> fundamental reset bit field.
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx <at> us.ibm.com>
> Signed-off-by: Richard Lary <rlary <at> us.ibm.com>

Signed-off-by: Linas Vepstas <linasvepstas <at> gmail.com>
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev <at> lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Permalink | Reply | 0 comments |
headers
Linas Vepstas | 2 Aug 2009 00:17
Picon
Gravatar

Re: [PATCH 2/3] Support for PCI Express reset type

2009/7/30 Mike Mason <mmlnx <at> us.ibm.com>:
> This is the second of three patches that implement a bit field that PCI
> Express device drivers can use to indicate they need a fundamental reset
> during error recovery.
>
> By default, the EEH framework on powerpc does what's known as a "hot reset"
> during recovery of a PCI Express device.  We've found a case where the
> device needs a "fundamental reset" to recover properly.  The current PCI
> error recovery and EEH frameworks do not support this distinction.
>
> The attached patch updates the Documentation/PCI/pci-error-recovery.txt file
> with changes related to this new bit field, as well a few unrelated updates.
>
> These patches supersede the previously submitted patch that implemented a
> fundamental reset bit field.
> Please review and let me know of any concerns.
>
> Signed-off-by: Mike Mason <mmlnx <at> us.ibm.com>
> Signed-off-by: Richard Lary <rlary <at> us.ibm.com>

FWIW,

Signed-off-by: Linas Vepstas <linasvepstas <at> gmail.com>
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev <at> lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Permalink | Reply | 0 comments |

Gmane