* Re: [PATCHv4 2/2] powerpc: implement arch_scale_smt_power for Power7
From: Michael Neuling @ 2010-02-19 11:01 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, linuxppc-dev, linux-kernel, ego
In-Reply-To: <1266573672.1806.70.camel@laptop>
In message <1266573672.1806.70.camel@laptop> you wrote:
> On Fri, 2010-02-19 at 17:05 +1100, Michael Neuling wrote:
> > > include/linux/sched.h | 2 +-
> > > kernel/sched_fair.c | 61 +++++++++++++++++++++++++++++++++++++++++++
++--
> > -
> > > 2 files changed, 58 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/include/linux/sched.h b/include/linux/sched.h
> > > index 0eef87b..42fa5c6 100644
> > > --- a/include/linux/sched.h
> > > +++ b/include/linux/sched.h
> > > @@ -849,7 +849,7 @@ enum cpu_idle_type {
> > > #define SD_POWERSAVINGS_BALANCE 0x0100 /* Balance for power savings */
> > > #define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg
> > resources */
> > > #define SD_SERIALIZE 0x0400 /* Only a single load balancing
instanc
> > e */
> > > -
> > > +#define SD_ASYM_PACKING 0x0800
> >
> > Would we eventually add this to SD_SIBLING_INIT in a arch specific hook,
> > or is this ok to add it generically?
>
> I'd think we'd want to keep that limited to architectures that actually
> need it.
OK
> >
> > > +static int update_sd_pick_busiest(struct sched_domain *sd,
> > > + struct sd_lb_stats *sds,
> > > + struct sched_group *sg,
> > > + struct sg_lb_stats *sgs)
> > > +{
> > > + if (sgs->sum_nr_running > sgs->group_capacity)
> > > + return 1;
> > > +
> > > + if (sgs->group_imb)
> > > + return 1;
> > > +
> > > + if ((sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running) {
> > > + if (!sds->busiest)
> > > + return 1;
> > > +
> > > + if (group_first_cpu(sds->busiest) < group_first_cpu(group))
> >
> > "group" => "sg" here? (I get a compile error otherwise)
>
> Oh, quite ;-)
>
> > > +static int check_asym_packing(struct sched_domain *sd,
> > > + struct sd_lb_stats *sds,
> > > + int cpu, unsigned long *imbalance)
> > > +{
> > > + int i, cpu, busiest_cpu;
> >
> > Redefining cpu here. Looks like the cpu parameter is not really needed?
>
> Seems that way indeed, I went back and forth a few times on the actual
> implementation of this function (which started out live as a copy of
> check_power_save_busiest_group), its amazing there were only these two
> compile glitches ;-)
:-)
Below are the cleanups + the arch specific bits. It doesn't change your
logic at all. Obviously the PPC arch bits would need to be split into a
separate patch.
Compiles and boots against linux-next.
Mikey
---
arch/powerpc/include/asm/cputable.h | 3 +
arch/powerpc/kernel/process.c | 7 +++
include/linux/sched.h | 4 +-
include/linux/topology.h | 1
kernel/sched_fair.c | 64 ++++++++++++++++++++++++++++++++++--
5 files changed, 74 insertions(+), 5 deletions(-)
Index: linux-next/arch/powerpc/include/asm/cputable.h
===================================================================
--- linux-next.orig/arch/powerpc/include/asm/cputable.h
+++ linux-next/arch/powerpc/include/asm/cputable.h
@@ -195,6 +195,7 @@ extern const char *powerpc_base_platform
#define CPU_FTR_SAO LONG_ASM_CONST(0x0020000000000000)
#define CPU_FTR_CP_USE_DCBTZ LONG_ASM_CONST(0x0040000000000000)
#define CPU_FTR_UNALIGNED_LD_STD LONG_ASM_CONST(0x0080000000000000)
+#define CPU_FTR_ASYM_SMT4 LONG_ASM_CONST(0x0100000000000000)
#ifndef __ASSEMBLY__
@@ -409,7 +410,7 @@ extern const char *powerpc_base_platform
CPU_FTR_MMCRA | CPU_FTR_SMT | \
CPU_FTR_COHERENT_ICACHE | CPU_FTR_LOCKLESS_TLBIE | \
CPU_FTR_PURR | CPU_FTR_SPURR | CPU_FTR_REAL_LE | \
- CPU_FTR_DSCR | CPU_FTR_SAO)
+ CPU_FTR_DSCR | CPU_FTR_SAO | CPU_FTR_ASYM_SMT4)
#define CPU_FTRS_CELL (CPU_FTR_USE_TB | CPU_FTR_LWSYNC | \
CPU_FTR_PPCAS_ARCH_V2 | CPU_FTR_CTRL | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_MMCRA | CPU_FTR_SMT | \
Index: linux-next/arch/powerpc/kernel/process.c
===================================================================
--- linux-next.orig/arch/powerpc/kernel/process.c
+++ linux-next/arch/powerpc/kernel/process.c
@@ -1265,3 +1265,10 @@ unsigned long randomize_et_dyn(unsigned
return ret;
}
+
+int arch_sd_asym_packing(void)
+{
+ if (cpu_has_feature(CPU_FTR_ASYM_SMT4))
+ return SD_ASYM_PACKING;
+ return 0;
+}
Index: linux-next/include/linux/sched.h
===================================================================
--- linux-next.orig/include/linux/sched.h
+++ linux-next/include/linux/sched.h
@@ -849,7 +849,7 @@ enum cpu_idle_type {
#define SD_POWERSAVINGS_BALANCE 0x0100 /* Balance for power savings */
#define SD_SHARE_PKG_RESOURCES 0x0200 /* Domain members share cpu pkg resources */
#define SD_SERIALIZE 0x0400 /* Only a single load balancing instance */
-
+#define SD_ASYM_PACKING 0x0800 /* Asymetric SMT packing */
#define SD_PREFER_SIBLING 0x1000 /* Prefer to place tasks in a sibling domain */
enum powersavings_balance_level {
@@ -881,6 +881,8 @@ static inline int sd_balance_for_package
return SD_PREFER_SIBLING;
}
+extern int arch_sd_asym_packing(void);
+
/*
* Optimise SD flags for power savings:
* SD_BALANCE_NEWIDLE helps agressive task consolidation and power savings.
Index: linux-next/include/linux/topology.h
===================================================================
--- linux-next.orig/include/linux/topology.h
+++ linux-next/include/linux/topology.h
@@ -102,6 +102,7 @@ int arch_update_cpu_topology(void);
| 1*SD_SHARE_PKG_RESOURCES \
| 0*SD_SERIALIZE \
| 0*SD_PREFER_SIBLING \
+ | arch_sd_asym_packing() \
, \
.last_balance = jiffies, \
.balance_interval = 1, \
Index: linux-next/kernel/sched_fair.c
===================================================================
--- linux-next.orig/kernel/sched_fair.c
+++ linux-next/kernel/sched_fair.c
@@ -2086,6 +2086,7 @@ struct sd_lb_stats {
struct sched_group *this; /* Local group in this sd */
unsigned long total_load; /* Total load of all groups in sd */
unsigned long total_pwr; /* Total power of all groups in sd */
+ unsigned long total_nr_running;
unsigned long avg_load; /* Average load across all groups in sd */
/** Statistics of this group */
@@ -2493,6 +2494,28 @@ static inline void update_sg_lb_stats(st
DIV_ROUND_CLOSEST(group->cpu_power, SCHED_LOAD_SCALE);
}
+static int update_sd_pick_busiest(struct sched_domain *sd,
+ struct sd_lb_stats *sds,
+ struct sched_group *sg,
+ struct sg_lb_stats *sgs)
+{
+ if (sgs->sum_nr_running > sgs->group_capacity)
+ return 1;
+
+ if (sgs->group_imb)
+ return 1;
+
+ if ((sd->flags & SD_ASYM_PACKING) && sgs->sum_nr_running) {
+ if (!sds->busiest)
+ return 1;
+
+ if (group_first_cpu(sds->busiest) < group_first_cpu(sg))
+ return 1;
+ }
+
+ return 0;
+}
+
/**
* update_sd_lb_stats - Update sched_group's statistics for load balancing.
* @sd: sched_domain whose statistics are to be updated.
@@ -2533,6 +2556,7 @@ static inline void update_sd_lb_stats(st
sds->total_load += sgs.group_load;
sds->total_pwr += group->cpu_power;
+ sds->total_nr_running += sgs.sum_nr_running;
/*
* In case the child domain prefers tasks go to siblings
@@ -2547,9 +2571,8 @@ static inline void update_sd_lb_stats(st
sds->this = group;
sds->this_nr_running = sgs.sum_nr_running;
sds->this_load_per_task = sgs.sum_weighted_load;
- } else if (sgs.avg_load > sds->max_load &&
- (sgs.sum_nr_running > sgs.group_capacity ||
- sgs.group_imb)) {
+ } else if (sgs.avg_load >= sds->max_load &&
+ update_sd_pick_busiest(sd, sds, group, &sgs)) {
sds->max_load = sgs.avg_load;
sds->busiest = group;
sds->busiest_nr_running = sgs.sum_nr_running;
@@ -2562,6 +2585,38 @@ static inline void update_sd_lb_stats(st
} while (group != sd->groups);
}
+int __weak sd_asym_packing_arch(void)
+{
+ return 0;
+}
+
+static int check_asym_packing(struct sched_domain *sd,
+ struct sd_lb_stats *sds,
+ unsigned long *imbalance)
+{
+ int i, cpu, busiest_cpu;
+
+ if (!(sd->flags & SD_ASYM_PACKING))
+ return 0;
+
+ if (!sds->busiest)
+ return 0;
+
+ i = 0;
+ busiest_cpu = group_first_cpu(sds->busiest);
+ for_each_cpu(cpu, sched_domain_span(sd)) {
+ i++;
+ if (cpu == busiest_cpu)
+ break;
+ }
+
+ if (sds->total_nr_running > i)
+ return 0;
+
+ *imbalance = sds->max_load;
+ return 1;
+}
+
/**
* fix_small_imbalance - Calculate the minor imbalance that exists
* amongst the groups of a sched_domain, during
@@ -2761,6 +2816,9 @@ find_busiest_group(struct sched_domain *
return sds.busiest;
out_balanced:
+ if (check_asym_packing(sd, &sds, imbalance))
+ return sds.busiest;
+
/*
* There is no obvious imbalance. But check if we can do some balancing
* to save power.
^ permalink raw reply
* ppc4xx emac support of phy-less devices patch + dts example
From: Staale.Aakermann @ 2010-02-19 12:32 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 4423 bytes --]
Hi,
I'm currently working on a custom embedded card with ppc405ex installed.
On this card, EMAC1 is "phy-less", and connected directly to a MAC on a micrel switch (ks8995ma).
I've tried the default phy-less mode currently supported by the core driver for ibm_newmac, but found
this insufficient. I've made a patch for the core driver so it supports some more scenarios.
Since the simultanious operation of both EMACS on PPC405EX requires utilization of the RGMII bridge, I did not
manage setting the speed to less than 1Gbps using the current phy-less mode. I've moved the phy-less setup to
the dts. I've also added a clock-internal which was required for my case, as the SDR0_MFR E1CS register was set
by default in phy-less mode.
--- drivers/net/ibm_newemac/core.c 2010-02-19 11:13:00.000000000 +0100
+++ drivers/net/ibm_newemac/core.c 2010-02-19 12:53:56.000000000 +0100
@@ -2393,14 +2393,54 @@
/* PHY-less configuration.
* XXX I probably should move these settings to the dev tree
*/
+
+ if (emac_read_uint_prop(np, "phy-duplex", &dev->phy.duplex, 0))
+ dev->phy.duplex = 1;
+
+ if (emac_read_uint_prop(np, "phy-speed", &dev->phy.speed, 0))
+ dev->phy.speed = 100;
+
+ if (emac_read_uint_prop(np, "phy-autoneg", &dev->phy.autoneg, 0))
+ dev->phy.autoneg = 0;
+
dev->phy.address = -1;
dev->phy.features = SUPPORTED_MII;
- if (emac_phy_supports_gige(dev->phy_mode))
- dev->phy.features |= SUPPORTED_1000baseT_Full;
- else
- dev->phy.features |= SUPPORTED_100baseT_Full;
+
+ if (dev->phy.autoneg == 1 )
+ dev->phy.features |= SUPPORTED_Autoneg;
+
+ switch (dev->phy.duplex)
+ {
+ case 0:
+
+ if (dev->phy.speed == 10 )
+ dev->phy.features |= SUPPORTED_10baseT_Half;
+
+ if (dev->phy.speed == 100 )
+ dev->phy.features |= SUPPORTED_100baseT_Half;
+
+ if (dev->phy.speed == 100 )
+ dev->phy.features |= SUPPORTED_100baseT_Half;
+
+ default:
+
+ if (dev->phy.speed == 10 )
+ dev->phy.features |= SUPPORTED_10baseT_Full;
+
+ if (dev->phy.speed == 100 )
+ dev->phy.features |= SUPPORTED_100baseT_Full;
+
+ if (dev->phy.speed == 100 )
+ dev->phy.features |= SUPPORTED_100baseT_Full;
+ }
+
dev->phy.pause = 1;
+ #if defined (CONFIG_PPC_DCR_NATIVE) && defined (CONFIG_405EX)
+ if (of_get_property(np, "phy-clock-internal", NULL))
+ dcri_clrset(SDR0, SDR0_MFR, ( dev->rgmii_port ? SDR0_MFR_ECS >> 1 : SDR0_MFR_ECS ),0 );
+ #endif
+
return 0;
}
DTS example:
EMAC1: ethernet@ef600a00 {
linux,network-index = <0x1>;
device_type = "network";
compatible = "ibm,emac-405ex", "ibm,emac4sync";
interrupt-parent = <&EMAC1>;
interrupts = <0x0 0x1>;
#interrupt-cells = <1>;
#address-cells = <0>;
#size-cells = <0>;
interrupt-map = </*Status*/ 0x0 &UIC0 0x19 0x4
/*Wake*/ 0x1 &UIC1 0x1f 0x4>;
reg = <0xef600a00 0x000000c4>;
local-mac-address = [0000000000];
mal-device = <&MAL0>;
mal-tx-channel = <1>;
mal-rx-channel = <1>;
cell-index = <1>;
max-frame-size = <9000>;
rx-fifo-size = <4096>;
tx-fifo-size = <2048>;
phy-mode = "rgmii";
phy-map = <0xffffffff>; // Be sure that the emac use phy-less configuration
phy-address = <0xffffffff>; // Be sure that the emac use phy-less configuration
phy-speed = <100>;
phy-duplex = <1>;
phy-autoneg = <0>;
phy-clock-internal;
rgmii-device = <&RGMII0>;
rgmii-channel = <1>;
has-inverted-stacr-oc;
has-new-stacr-staopc;
};
Best regards
Staale Aakermann, Systems Engineer
Kongsberg Defence Systems / Defence Communication
Olav Brunborgsv 6, P.O.Box 87, 1375 Billingstad, Norway
Phone: +47 66 84 24 00, Direct Phone: +47 66 74 48 51,
Fax: +47 66 84 82 30, Mobile: +47 928 29 879
Mail: staale.aakermann@kongsberg.com<mailto:staale.aakermann@kongsberg.com>
Url: www.kongsberg.com<http://www.kongsberg.com/>
[-- Attachment #2: Type: text/html, Size: 24620 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Mel Gorman @ 2010-02-19 14:55 UTC (permalink / raw)
To: Anton Blanchard; +Cc: cl, linuxppc-dev
In-Reply-To: <20100219000730.GD31681@kryten>
On Fri, Feb 19, 2010 at 11:07:30AM +1100, Anton Blanchard wrote:
>
> Hi,
>
> > The patch below sets a smaller value for RECLAIM_DISTANCE and thus enables
> > zone reclaim.
>
I've no problem with the patch anyway.
> FYI even with this enabled I could trip it up pretty easily with a multi
> threaded application. I tried running stream across all threads in node 0. The
> machine looks like:
>
> node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
> node 0 free: 30254 MB
> node 1 cpus: 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
> node 1 free: 31832 MB
>
> Now create some clean pagecache on node 0:
>
> # taskset -c 0 dd if=/dev/zero of=/tmp/bigfile bs=1G count=16
> # sync
>
> node 0 free: 12880 MB
> node 1 free: 31830 MB
>
> I built stream to use about 25GB of memory. I then ran stream across all
> threads in node 0:
>
> # OMP_NUM_THREADS=16 taskset -c 0-15 ./stream
>
> We exhaust all memory on node 0, and start using memory on node 1:
>
> node 0 free: 0 MB
> node 1 free: 20795 MB
>
> ie about 10GB of node 1. Now if we run the same test with one thread:
>
> # OMP_NUM_THREADS=1 taskset -c 0 ./stream
>
> things are much better:
>
> node 0 free: 11 MB
> node 1 free: 31552 MB
>
> Interestingly enough it takes two goes to get completely onto node 0, even
> with one thread. The second run looks like:
>
> node 0 free: 14 MB
> node 1 free: 31811 MB
>
> I had a quick look at the page allocation logic and I think I understand why
> we would have issues with multple threads all trying to allocate at once.
>
> - The ZONE_RECLAIM_LOCKED flag allows only one thread into zone reclaim at
> a time, and whatever thread is in zone reclaim probably only frees a small
> amount of memory. Certainly not enough to satisfy all 16 threads.
>
> - We seem to end up racing between zone_watermark_ok, zone_reclaim and
> buffered_rmqueue. Since everyone is in here the memory one thread reclaims
> may be stolen by another thread.
>
You're pretty much on the button here. Only one thread at a time enters
zone_reclaim. The others back off and try the next zone in the zonelist
instead. I'm not sure what the original intention was but most likely it
was to prevent too many parallel reclaimers in the same zone potentially
dumping out way more data than necessary.
> I'm not sure if there is an easy way to fix this without penalising other
> workloads though.
>
You could experiment with waiting on the bit if the GFP flags allowi it? The
expectation would be that the reclaim operation does not take long. Wait
on the bit, if you are making the forward progress, recheck the
watermarks before continueing.
--
Mel Gorman
Part-time Phd Student Linux Technology Center
University of Limerick IBM Dublin Software Lab
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Christoph Lameter @ 2010-02-19 15:12 UTC (permalink / raw)
To: Mel Gorman; +Cc: linuxppc-dev, Anton Blanchard
In-Reply-To: <20100219145523.GN30258@csn.ul.ie>
On Fri, 19 Feb 2010, Mel Gorman wrote:
> > > The patch below sets a smaller value for RECLAIM_DISTANCE and thus enables
> > > zone reclaim.
> >
>
> I've no problem with the patch anyway.
Nor do I.
> > - We seem to end up racing between zone_watermark_ok, zone_reclaim and
> > buffered_rmqueue. Since everyone is in here the memory one thread reclaims
> > may be stolen by another thread.
> >
>
> You're pretty much on the button here. Only one thread at a time enters
> zone_reclaim. The others back off and try the next zone in the zonelist
> instead. I'm not sure what the original intention was but most likely it
> was to prevent too many parallel reclaimers in the same zone potentially
> dumping out way more data than necessary.
Yes it was to prevent concurrency slowing down reclaim. At that time the
number of processors per NUMA node was 2 or so. The number of pages that
are reclaimed is limited to avoid tossing too many page cache pages.
> You could experiment with waiting on the bit if the GFP flags allowi it? The
> expectation would be that the reclaim operation does not take long. Wait
> on the bit, if you are making the forward progress, recheck the
> watermarks before continueing.
You could reclaim more pages during a zone reclaim pass? Increase the
nr_to_reclaim in __zone_reclaim() and see if that helps. One zone reclaim
pass should reclaim enough local pages to keep the processors on a node
happy for a reasonable interval. Maybe do a fraction of a zone? 1/16th?
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Balbir Singh @ 2010-02-19 15:41 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Mel Gorman, linuxppc-dev, Anton Blanchard
In-Reply-To: <alpine.DEB.2.00.1002190906190.7486@router.home>
On Fri, Feb 19, 2010 at 8:42 PM, Christoph Lameter
<cl@linux-foundation.org> wrote:
> On Fri, 19 Feb 2010, Mel Gorman wrote:
>
>> > > The patch below sets a smaller value for RECLAIM_DISTANCE and thus e=
nables
>> > > zone reclaim.
>> >
>>
>> I've no problem with the patch anyway.
>
> Nor do I.
>
>> > - We seem to end up racing between zone_watermark_ok, zone_reclaim and
>> > =A0 buffered_rmqueue. Since everyone is in here the memory one thread =
reclaims
>> > =A0 may be stolen by another thread.
>> >
>>
>> You're pretty much on the button here. Only one thread at a time enters
>> zone_reclaim. The others back off and try the next zone in the zonelist
>> instead. I'm not sure what the original intention was but most likely it
>> was to prevent too many parallel reclaimers in the same zone potentially
>> dumping out way more data than necessary.
>
> Yes it was to prevent concurrency slowing down reclaim. At that time the
> number of processors per NUMA node was 2 or so. The number of pages that
> are reclaimed is limited to avoid tossing too many page cache pages.
>
That is interesting, I always thought it was to try and free page
cache first. For example with zone->min_unmapped_pages, if
zone_pagecache_reclaimable is greater than unmapped pages, we start
reclaim the cached pages first. The min_unmapped_pages almost sounds
like the higher level watermark - or am I misreading the code.
Balbir Singh
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Balbir Singh @ 2010-02-19 15:43 UTC (permalink / raw)
To: Anton Blanchard; +Cc: mel, cl, linuxppc-dev
In-Reply-To: <20100218222923.GC31681@kryten>
On Fri, Feb 19, 2010 at 3:59 AM, Anton Blanchard <anton@samba.org> wrote:
>
> I noticed /proc/sys/vm/zone_reclaim_mode was 0 on a ppc64 NUMA box. It ge=
ts
> enabled via this:
>
> =A0 =A0 =A0 =A0/*
> =A0 =A0 =A0 =A0 * If another node is sufficiently far away then it is bet=
ter
> =A0 =A0 =A0 =A0 * to reclaim pages in a zone before going off node.
> =A0 =A0 =A0 =A0 */
> =A0 =A0 =A0 =A0if (distance > RECLAIM_DISTANCE)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0zone_reclaim_mode =3D 1;
>
> Since we use the default value of 20 for REMOTE_DISTANCE and 20 for
> RECLAIM_DISTANCE it never kicks in.
>
> The local to remote bandwidth ratios can be quite large on System p
> machines so it makes sense for us to reclaim clean pagecache locally befo=
re
> going off node.
>
> The patch below sets a smaller value for RECLAIM_DISTANCE and thus enable=
s
> zone reclaim.
>
A reclaim distance of 10 implies a ratio of 1, that means we'll always
do zone_reclaim() to free page cache and slab cache before moving on
to another node?
Balbir Singh.
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Christoph Lameter @ 2010-02-19 15:51 UTC (permalink / raw)
To: Balbir Singh; +Cc: Mel Gorman, linuxppc-dev, Anton Blanchard
In-Reply-To: <661de9471002190741k34ddb1acidf64d089bf9ff284@mail.gmail.com>
On Fri, 19 Feb 2010, Balbir Singh wrote:
> >> zone_reclaim. The others back off and try the next zone in the zonelist
> >> instead. I'm not sure what the original intention was but most likely it
> >> was to prevent too many parallel reclaimers in the same zone potentially
> >> dumping out way more data than necessary.
> >
> > Yes it was to prevent concurrency slowing down reclaim. At that time the
> > number of processors per NUMA node was 2 or so. The number of pages that
> > are reclaimed is limited to avoid tossing too many page cache pages.
> >
>
> That is interesting, I always thought it was to try and free page
> cache first. For example with zone->min_unmapped_pages, if
> zone_pagecache_reclaimable is greater than unmapped pages, we start
> reclaim the cached pages first. The min_unmapped_pages almost sounds
> like the higher level watermark - or am I misreading the code.
Indeed the purpose is to free *old* page cache pages.
The min_unmapped_pages is to protect a mininum of the page cache pages /
fs metadata from zone reclaim so that ongoing file I/O is not impacted.
^ permalink raw reply
* anyone used the Marvell mv64560?
From: Chris Friesen @ 2010-02-19 16:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt, paulus, linuxppc-dev
Is anyone familiar with the mv64560? I'm curious how much difference
there might be from the older mv64360 as far as setting up the PCI bus,
cpu bus, i2c, memory, etc.
I don't see any mention of this chip in current linux sources, but
there's some mention of people trying it and it's referenced in one of
the text files in Documentation...is it supported? Are there any caveats?
We'll be going through proper channels eventually but I thought I'd
check here just in case.
Any information appreciated.
Thanks,
Chris
^ permalink raw reply
* Re: [PATCH] eeh: Fixing a bug when pci structure is null
From: Breno Leitao @ 2010-02-19 16:43 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Linas Vepstas
In-Reply-To: <4B699CB9.3030605@linux.vnet.ibm.com>
Hi Ben,
I'd like to ask about this patch ? Should I re-submit ?
Thanks,
Breno Leitao wrote:
> During a EEH recover, the pci_dev structure can be null, mainly if an
> eeh event is detected during cpi config operation. In this case, the
> pci_dev will not be known (and will be null) the kernel will crash
> with the following message:
^ permalink raw reply
* Re: [PATCH] eeh: Fixing a bug when pci structure is null
From: Linas Vepstas @ 2010-02-19 17:05 UTC (permalink / raw)
To: Breno Leitao, Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <4B7EBF9A.7020801@linux.vnet.ibm.com>
Hi Paul, Breno,
Some confusion -- I've been out of the loop for a while -- I assume
its still Paul who is pushing
these patches upstream, and not Ben? So Breno, maybe you should
resend the patch to Paul?
--linas
On 19 February 2010 10:43, Breno Leitao <leitao@linux.vnet.ibm.com> wrote:
> Hi Ben,
>
> I'd like to ask about this patch ? Should I re-submit ?
>
> Thanks,
>
> Breno Leitao wrote:
>> During a EEH recover, the pci_dev structure can be null, mainly if an
>> eeh event is detected during cpi config operation. In this case, the
>> pci_dev will not be known (and will be null) the kernel will crash
>> with the following message:
>
^ permalink raw reply
* Re: [PATCH] powerpc: Set a smaller value for RECLAIM_DISTANCE to enable zone reclaim
From: Balbir Singh @ 2010-02-19 17:39 UTC (permalink / raw)
To: Christoph Lameter; +Cc: Mel Gorman, linuxppc-dev, Anton Blanchard
In-Reply-To: <alpine.DEB.2.00.1002190948200.26567@router.home>
* Christoph Lameter <cl@linux-foundation.org> [2010-02-19 09:51:12]:
> On Fri, 19 Feb 2010, Balbir Singh wrote:
>
> > >> zone_reclaim. The others back off and try the next zone in the zonelist
> > >> instead. I'm not sure what the original intention was but most likely it
> > >> was to prevent too many parallel reclaimers in the same zone potentially
> > >> dumping out way more data than necessary.
> > >
> > > Yes it was to prevent concurrency slowing down reclaim. At that time the
> > > number of processors per NUMA node was 2 or so. The number of pages that
> > > are reclaimed is limited to avoid tossing too many page cache pages.
> > >
> >
> > That is interesting, I always thought it was to try and free page
> > cache first. For example with zone->min_unmapped_pages, if
> > zone_pagecache_reclaimable is greater than unmapped pages, we start
> > reclaim the cached pages first. The min_unmapped_pages almost sounds
> > like the higher level watermark - or am I misreading the code.
>
> Indeed the purpose is to free *old* page cache pages.
>
> The min_unmapped_pages is to protect a mininum of the page cache pages /
> fs metadata from zone reclaim so that ongoing file I/O is not impacted.
Thanks for the explanation!
--
Three Cheers,
Balbir
^ permalink raw reply
* Re: MPC5200B XLB Configuration Issues, FEC RFIFO Events, ATA Crashes
From: Albrecht Dreß @ 2010-02-19 18:04 UTC (permalink / raw)
To: Roman Fietze; +Cc: linuxppc-dev
In-Reply-To: <1265312112.2256.1@antares>
[-- Attachment #1: Type: text/plain, Size: 2295 bytes --]
Hi Roman:
Sorry for the long delay, I had to fix some other stuff first, before I could launch the test... Here is just a short intermediate result.
Am 04.02.10 20:35 schrieb(en) Albrecht Dreß:
> Actually, I forgot that I have to explicitly enable libata dma on the 5200b, due to the known silicon bugs... I will repeat my tests with the proper configuration, stay tuned.
>
>>> ... a signal processor attached to the localbus, using bestcomm and the fifo for the bulk transfer
>>
>> Are you using an own driver, or are you using Grant's SCLPC+SDMA driver? BD task?
>
> Basically Grant's driver, but with a slightly modified variant of the gen_bd task. The signal processor is a LE, and I managed to insert the LE/BE conversion into the bestcomm task (see also <http://patchwork.ozlabs.org/patch/35038/>). Unfortunately, there is no good documentation of the engine; I would like to also shift crc calculation into bestcomm, which seems to be possible in principle, but I never got it running.
>
>> The best thing is to run very ugly tests with very high load for at least 24h.
I today launched my test application, on kernel 2.6.32 with a few minor tweaks, which runs 4 threads in parallel, all first writing a number of data blocks, then doing a sync() when appropriate, and reading reading them all back and checking the contents (md5 hash):
- one writes/reads back 256 files of 256k each to a nfs3 share on a Xeon server, using a 100 MBit line;
- one writes/reads back one 1 MByte block using BestComm to a Localbus device (see quote above);
- two write/read back 128 files of 64k each to two CF cards w/ vfat, both attached to the ata (master/slave).
Booting with 'libata.force=mwdma2', this tests reproducibly freezes the system *within a few minutes*, in one case leaving the vfat fs on one card completely broken. The system didn't throw a panic, it was always simply stuck - no response to the serial console, nothing.
Booting *without* this option (i.e. using pio for the cf cards), the system seems to run flawlessly. I will continue the test over the weekend (now active for ~5 hours), but it looks as if I can reproduce your problem. Next week, I'll try your fix (hope I don't wear out the cf cards...), and re-run the test.
Best, Albrecht.
[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: State of PREEMPT_RT in PPC arch
From: Ryan @ 2010-02-19 18:11 UTC (permalink / raw)
To: Wolfram Sang; +Cc: ppcdev
In-Reply-To: <20100219085450.GA10674@pengutronix.de>
Hi Wolfram,
On Fri, Feb 19, 2010 at 12:54 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
>
> The list was apropriate. As all people are busy by default, getting no response
> is not that exceptional. If you need a fast response, you should consider
> commercial support.
I appreciate your comments.
-Ryan.
^ permalink raw reply
* Re: register long sp asm("r1") incorrect
From: Pavel Machek @ 2010-02-18 22:57 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: kernel list, linuxppc-dev, paulus
In-Reply-To: <4B79C775.1050903@zytor.com>
On Mon 2010-02-15 14:15:17, H. Peter Anvin wrote:
> On 02/15/2010 01:04 PM, Benjamin Herrenschmidt wrote:
> >
> > It's true that most other use of it we have are global scope (local_paca
> > in r13, glibc use of r2/r13, etc...) afaik, but since r1 itself is the
> > stack pointer always, I think they pretty much guarantee it works.
> >
>
> It should work, because r1, being the stack pointer, is already marked a
> reserved register in gcc.
>
> The reference Pavel is citing bascially states that gcc won't globally
> reserve the register, which is true, but it is already reserved anyway.
Ok, thanks for clarification.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH] eeh: Fixing a bug when pci structure is null
From: Benjamin Herrenschmidt @ 2010-02-19 21:54 UTC (permalink / raw)
To: Breno Leitao; +Cc: linuxppc-dev, Linas Vepstas
In-Reply-To: <4B7EBF9A.7020801@linux.vnet.ibm.com>
On Fri, 2010-02-19 at 14:43 -0200, Breno Leitao wrote:
> Hi Ben,
>
> I'd like to ask about this patch ? Should I re-submit ?
>
> Thanks,
>
> Breno Leitao wrote:
> > During a EEH recover, the pci_dev structure can be null, mainly if an
> > eeh event is detected during cpi config operation. In this case, the
> > pci_dev will not be known (and will be null) the kernel will crash
> > with the following message:
It should be in -next, can you dbl check ?
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] eeh: Fixing a bug when pci structure is null
From: Benjamin Herrenschmidt @ 2010-02-19 21:55 UTC (permalink / raw)
To: linasvepstas; +Cc: linuxppc-dev, Paul Mackerras, Breno Leitao
In-Reply-To: <3ae3aa421002190905l67e9f235he9537aeb0e56790e@mail.gmail.com>
On Fri, 2010-02-19 at 11:05 -0600, Linas Vepstas wrote:
>
> Some confusion -- I've been out of the loop for a while -- I assume
> its still Paul who is pushing
> these patches upstream, and not Ben? So Breno, maybe you should
> resend the patch to Paul?
No, it's me.
Cheers,
Ben.
^ permalink raw reply
* hrtimers in powerpc arch?
From: Xiaogeng Jin @ 2010-02-20 1:16 UTC (permalink / raw)
To: ppcdev
Hi,
Is hrtimers supported in the powerpc arch and used in embedded powerpc
drivers? I greped ktime_t and hrtimer_start() under arch/powerpc and
found not two many calls. Does it indicate the powerpc world doesn't
use hrtimers?
Thanks,
-Ryan.
^ permalink raw reply
* i need to patch form powerpc405
From: ahmed zemoji @ 2010-02-20 8:10 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 333 bytes --]
help me !!!!
i like emmbedded a kernel linux 2.6 to processor powerpc405 of card ML403
please
please
..
help me
_________________________________________________________________
Hotmail : une messagerie fiable avec une protection anti-spam performante
https://signup.live.com/signup.aspx?id=60969
[-- Attachment #2: Type: text/html, Size: 528 bytes --]
^ permalink raw reply
* Re: hrtimers in powerpc arch?
From: Benjamin Herrenschmidt @ 2010-02-20 21:07 UTC (permalink / raw)
To: Xiaogeng Jin; +Cc: ppcdev
In-Reply-To: <5bbdacc81002191716q4929f72ao30215859bd080465@mail.gmail.com>
On Fri, 2010-02-19 at 17:16 -0800, Xiaogeng Jin wrote:
> Is hrtimers supported in the powerpc arch and used in embedded powerpc
> drivers? I greped ktime_t and hrtimer_start() under arch/powerpc and
> found not two many calls. Does it indicate the powerpc world doesn't
> use hrtimers?
They are there and should work just fine. Why would we "use" them from
arch code ?
Cheers,
Ben.
^ permalink raw reply
* Re: i need to patch form powerpc405
From: David Baird @ 2010-02-20 22:42 UTC (permalink / raw)
To: ahmed zemoji; +Cc: linuxppc-dev
In-Reply-To: <BLU133-W1CA05E2983D07AF546E2A9B450@phx.gbl>
2010/2/20 ahmed zemoji <z.mouni14@hotmail.fr>:
> help me !!!!
> i like emmbedded a kernel linux 2.6 to processor powerpc405 of card ML403
> please
Have you seen these two resources yet?
http://xilinx.wikidot.com/
http://git.xilinx.com/cgi-bin/gitweb.cgi
(these kind of assume that you have EDK too...)
-David
^ permalink raw reply
* [PATCH 2/3] backlight: mark struct backlight_ops const
From: Bruno Prémont @ 2010-02-20 23:18 UTC (permalink / raw)
To: Andrew Morton, Greg Kroah-Hartman
Cc: devel, linux-fbdev, linux-usb, linuxppc-dev, acpi4asus-user,
linux-kernel, linux-acpi, linux-omap, dri-devel, ibm-acpi-devel
In-Reply-To: <20100221001049.2f63f5d6@neptune.home>
Signed-off-by: Bruno Pr=C3=A9mont <bonbons@linux-vserver.org>
---
drivers/acpi/video.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_backlight.c | 4 ++--
drivers/macintosh/via-pmu-backlight.c | 4 ++--
drivers/platform/x86/acer-wmi.c | 2 +-
drivers/platform/x86/asus-laptop.c | 2 +-
drivers/platform/x86/asus_acpi.c | 2 +-
drivers/platform/x86/classmate-laptop.c | 2 +-
drivers/platform/x86/compal-laptop.c | 2 +-
drivers/platform/x86/dell-laptop.c | 2 +-
drivers/platform/x86/eeepc-laptop.c | 2 +-
drivers/platform/x86/fujitsu-laptop.c | 2 +-
drivers/platform/x86/msi-laptop.c | 2 +-
drivers/platform/x86/msi-wmi.c | 2 +-
drivers/platform/x86/panasonic-laptop.c | 2 +-
drivers/platform/x86/sony-laptop.c | 2 +-
drivers/platform/x86/thinkpad_acpi.c | 2 +-
drivers/platform/x86/toshiba_acpi.c | 2 +-
drivers/staging/samsung-laptop/samsung-laptop.c | 2 +-
drivers/usb/misc/appledisplay.c | 2 +-
drivers/video/atmel_lcdfb.c | 2 +-
drivers/video/aty/aty128fb.c | 2 +-
drivers/video/aty/atyfb_base.c | 2 +-
drivers/video/aty/radeon_backlight.c | 2 +-
drivers/video/bf54x-lq043fb.c | 2 +-
drivers/video/bfin-t350mcqb-fb.c | 2 +-
drivers/video/nvidia/nv_backlight.c | 2 +-
drivers/video/omap2/displays/panel-taal.c | 2 +-
drivers/video/riva/fbdev.c | 2 +-
28 files changed, 30 insertions(+), 30 deletions(-)
diff --git a/drivers/acpi/video.c b/drivers/acpi/video.c
index b765790..c86c401 100644
--- a/drivers/acpi/video.c
+++ b/drivers/acpi/video.c
@@ -366,7 +366,7 @@ static int acpi_video_set_brightness(struct backlight_d=
evice *bd)
vd->brightness->levels[request_level]);
}
=20
-static struct backlight_ops acpi_backlight_ops =3D {
+static const struct backlight_ops acpi_backlight_ops =3D {
.get_brightness =3D acpi_video_get_brightness,
.update_status =3D acpi_video_set_brightness,
};
diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/=
nouveau/nouveau_backlight.c
index 20564f8..9a8c990 100644
--- a/drivers/gpu/drm/nouveau/nouveau_backlight.c
+++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c
@@ -58,7 +58,7 @@ static int nv40_set_intensity(struct backlight_device *bd)
return 0;
}
=20
-static struct backlight_ops nv40_bl_ops =3D {
+static const struct backlight_ops nv40_bl_ops =3D {
.options =3D BL_CORE_SUSPENDRESUME,
.get_brightness =3D nv40_get_intensity,
.update_status =3D nv40_set_intensity,
@@ -81,7 +81,7 @@ static int nv50_set_intensity(struct backlight_device *bd)
return 0;
}
=20
-static struct backlight_ops nv50_bl_ops =3D {
+static const struct backlight_ops nv50_bl_ops =3D {
.options =3D BL_CORE_SUSPENDRESUME,
.get_brightness =3D nv50_get_intensity,
.update_status =3D nv50_set_intensity,
diff --git a/drivers/macintosh/via-pmu-backlight.c b/drivers/macintosh/via-=
pmu-backlight.c
index a348bb0..ecd9b3f 100644
--- a/drivers/macintosh/via-pmu-backlight.c
+++ b/drivers/macintosh/via-pmu-backlight.c
@@ -15,7 +15,7 @@
=20
#define MAX_PMU_LEVEL 0xFF
=20
-static struct backlight_ops pmu_backlight_data;
+static const struct backlight_ops pmu_backlight_data;
static DEFINE_SPINLOCK(pmu_backlight_lock);
static int sleeping, uses_pmu_bl;
static u8 bl_curve[FB_BACKLIGHT_LEVELS];
@@ -115,7 +115,7 @@ static int pmu_backlight_get_brightness(struct backligh=
t_device *bd)
return bd->props.brightness;
}
=20
-static struct backlight_ops pmu_backlight_data =3D {
+static const struct backlight_ops pmu_backlight_data =3D {
.get_brightness =3D pmu_backlight_get_brightness,
.update_status =3D pmu_backlight_update_status,
=20
diff --git a/drivers/platform/x86/acer-wmi.c b/drivers/platform/x86/acer-wm=
i.c
index 07d14df..f70bd41 100644
--- a/drivers/platform/x86/acer-wmi.c
+++ b/drivers/platform/x86/acer-wmi.c
@@ -915,7 +915,7 @@ static int update_bl_status(struct backlight_device *bd)
return 0;
}
=20
-static struct backlight_ops acer_bl_ops =3D {
+static const struct backlight_ops acer_bl_ops =3D {
.get_brightness =3D read_brightness,
.update_status =3D update_bl_status,
};
diff --git a/drivers/platform/x86/asus-laptop.c b/drivers/platform/x86/asus=
-laptop.c
index 61a1c75..88e8554 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -251,7 +251,7 @@ static struct backlight_device *asus_backlight_device;
*/
static int read_brightness(struct backlight_device *bd);
static int update_bl_status(struct backlight_device *bd);
-static struct backlight_ops asusbl_ops =3D {
+static const struct backlight_ops asusbl_ops =3D {
.get_brightness =3D read_brightness,
.update_status =3D update_bl_status,
};
diff --git a/drivers/platform/x86/asus_acpi.c b/drivers/platform/x86/asus_a=
cpi.c
index c1d2aee..9980d51 100644
--- a/drivers/platform/x86/asus_acpi.c
+++ b/drivers/platform/x86/asus_acpi.c
@@ -1464,7 +1464,7 @@ static int asus_hotk_remove(struct acpi_device *devic=
e, int type)
return 0;
}
=20
-static struct backlight_ops asus_backlight_data =3D {
+static const struct backlight_ops asus_backlight_data =3D {
.get_brightness =3D read_brightness,
.update_status =3D set_brightness_status,
};
diff --git a/drivers/platform/x86/classmate-laptop.c b/drivers/platform/x86=
/classmate-laptop.c
index ed90082..bfae789 100644
--- a/drivers/platform/x86/classmate-laptop.c
+++ b/drivers/platform/x86/classmate-laptop.c
@@ -452,7 +452,7 @@ static int cmpc_bl_update_status(struct backlight_devic=
e *bd)
return -1;
}
=20
-static struct backlight_ops cmpc_bl_ops =3D {
+static const struct backlight_ops cmpc_bl_ops =3D {
.get_brightness =3D cmpc_bl_get_brightness,
.update_status =3D cmpc_bl_update_status
};
diff --git a/drivers/platform/x86/compal-laptop.c b/drivers/platform/x86/co=
mpal-laptop.c
index 1a387e7..2bd6c65 100644
--- a/drivers/platform/x86/compal-laptop.c
+++ b/drivers/platform/x86/compal-laptop.c
@@ -162,7 +162,7 @@ static int bl_update_status(struct backlight_device *b)
return set_lcd_level(b->props.brightness);
}
=20
-static struct backlight_ops compalbl_ops =3D {
+static const struct backlight_ops compalbl_ops =3D {
.get_brightness =3D bl_get_brightness,
.update_status =3D bl_update_status,
};
diff --git a/drivers/platform/x86/dell-laptop.c b/drivers/platform/x86/dell=
-laptop.c
index 3780994..55640e5 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -333,7 +333,7 @@ static int dell_get_intensity(struct backlight_device *=
bd)
return buffer.output[1];
}
=20
-static struct backlight_ops dell_ops =3D {
+static const struct backlight_ops dell_ops =3D {
.get_brightness =3D dell_get_intensity,
.update_status =3D dell_send_intensity,
};
diff --git a/drivers/platform/x86/eeepc-laptop.c b/drivers/platform/x86/eee=
pc-laptop.c
index e2be6bb..4f77774 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1096,7 +1096,7 @@ static int update_bl_status(struct backlight_device *=
bd)
return set_brightness(bd, bd->props.brightness);
}
=20
-static struct backlight_ops eeepcbl_ops =3D {
+static const struct backlight_ops eeepcbl_ops =3D {
.get_brightness =3D read_brightness,
.update_status =3D update_bl_status,
};
diff --git a/drivers/platform/x86/fujitsu-laptop.c b/drivers/platform/x86/f=
ujitsu-laptop.c
index 5f3320d..b6a0941 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -436,7 +436,7 @@ static int bl_update_status(struct backlight_device *b)
return ret;
}
=20
-static struct backlight_ops fujitsubl_ops =3D {
+static const struct backlight_ops fujitsubl_ops =3D {
.get_brightness =3D bl_get_brightness,
.update_status =3D bl_update_status,
};
diff --git a/drivers/platform/x86/msi-laptop.c b/drivers/platform/x86/msi-l=
aptop.c
index 759763d..1093ba2 100644
--- a/drivers/platform/x86/msi-laptop.c
+++ b/drivers/platform/x86/msi-laptop.c
@@ -161,7 +161,7 @@ static int bl_update_status(struct backlight_device *b)
return set_lcd_level(b->props.brightness);
}
=20
-static struct backlight_ops msibl_ops =3D {
+static const struct backlight_ops msibl_ops =3D {
.get_brightness =3D bl_get_brightness,
.update_status =3D bl_update_status,
};
diff --git a/drivers/platform/x86/msi-wmi.c b/drivers/platform/x86/msi-wmi.c
index f5f70d4..5f7cff1 100644
--- a/drivers/platform/x86/msi-wmi.c
+++ b/drivers/platform/x86/msi-wmi.c
@@ -138,7 +138,7 @@ static int bl_set_status(struct backlight_device *bd)
return msi_wmi_set_block(0, backlight_map[bright]);
}
=20
-static struct backlight_ops msi_backlight_ops =3D {
+static const struct backlight_ops msi_backlight_ops =3D {
.get_brightness =3D bl_get,
.update_status =3D bl_set_status,
};
diff --git a/drivers/platform/x86/panasonic-laptop.c b/drivers/platform/x86=
/panasonic-laptop.c
index fe7cf01..9012d8d 100644
--- a/drivers/platform/x86/panasonic-laptop.c
+++ b/drivers/platform/x86/panasonic-laptop.c
@@ -352,7 +352,7 @@ static int bl_set_status(struct backlight_device *bd)
return acpi_pcc_write_sset(pcc, SINF_DC_CUR_BRIGHT, bright);
}
=20
-static struct backlight_ops pcc_backlight_ops =3D {
+static const struct backlight_ops pcc_backlight_ops =3D {
.get_brightness =3D bl_get,
.update_status =3D bl_set_status,
};
diff --git a/drivers/platform/x86/sony-laptop.c b/drivers/platform/x86/sony=
-laptop.c
index 3f71a60..75481e6 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -853,7 +853,7 @@ static int sony_backlight_get_brightness(struct backlig=
ht_device *bd)
}
=20
static struct backlight_device *sony_backlight_device;
-static struct backlight_ops sony_backlight_ops =3D {
+static const struct backlight_ops sony_backlight_ops =3D {
.update_status =3D sony_backlight_update_status,
.get_brightness =3D sony_backlight_get_brightness,
};
diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/th=
inkpad_acpi.c
index e67e4fe..950a2f7 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -6112,7 +6112,7 @@ static void tpacpi_brightness_notify_change(void)
BACKLIGHT_UPDATE_HOTKEY);
}
=20
-static struct backlight_ops ibm_backlight_data =3D {
+static const struct backlight_ops ibm_backlight_data =3D {
.get_brightness =3D brightness_get,
.update_status =3D brightness_update_status,
};
diff --git a/drivers/platform/x86/toshiba_acpi.c b/drivers/platform/x86/tos=
hiba_acpi.c
index 77bf5d8..0f0b69e 100644
--- a/drivers/platform/x86/toshiba_acpi.c
+++ b/drivers/platform/x86/toshiba_acpi.c
@@ -706,7 +706,7 @@ static acpi_status remove_device(void)
return AE_OK;
}
=20
-static struct backlight_ops toshiba_backlight_data =3D {
+static const struct backlight_ops toshiba_backlight_data =3D {
.get_brightness =3D get_lcd,
.update_status =3D set_lcd_status,
};
diff --git a/drivers/staging/samsung-laptop/samsung-laptop.c b/drivers/stag=
ing/samsung-laptop/samsung-laptop.c
index 4877138..0cf2d58 100644
--- a/drivers/staging/samsung-laptop/samsung-laptop.c
+++ b/drivers/staging/samsung-laptop/samsung-laptop.c
@@ -268,7 +268,7 @@ static int update_status(struct backlight_device *bd)
return 0;
}
=20
-static struct backlight_ops backlight_ops =3D {
+static const struct backlight_ops backlight_ops =3D {
.get_brightness =3D get_brightness,
.update_status =3D update_status,
};
diff --git a/drivers/usb/misc/appledisplay.c b/drivers/usb/misc/appledispla=
y.c
index 1eb9e41..ef79ca2 100644
--- a/drivers/usb/misc/appledisplay.c
+++ b/drivers/usb/misc/appledisplay.c
@@ -179,7 +179,7 @@ static int appledisplay_bl_get_brightness(struct backli=
ght_device *bd)
return pdata->msgdata[1];
}
=20
-static struct backlight_ops appledisplay_bl_data =3D {
+static const struct backlight_ops appledisplay_bl_data =3D {
.get_brightness =3D appledisplay_bl_get_brightness,
.update_status =3D appledisplay_bl_update_status,
};
diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
index 3d886c6..22ee7f8 100644
--- a/drivers/video/atmel_lcdfb.c
+++ b/drivers/video/atmel_lcdfb.c
@@ -110,7 +110,7 @@ static int atmel_bl_get_brightness(struct backlight_dev=
ice *bl)
return lcdc_readl(sinfo, ATMEL_LCDC_CONTRAST_VAL);
}
=20
-static struct backlight_ops atmel_lcdc_bl_ops =3D {
+static const struct backlight_ops atmel_lcdc_bl_ops =3D {
.update_status =3D atmel_bl_update_status,
.get_brightness =3D atmel_bl_get_brightness,
};
diff --git a/drivers/video/aty/aty128fb.c b/drivers/video/aty/aty128fb.c
index e4e4d43..137cd34 100644
--- a/drivers/video/aty/aty128fb.c
+++ b/drivers/video/aty/aty128fb.c
@@ -1787,7 +1787,7 @@ static int aty128_bl_get_brightness(struct backlight_=
device *bd)
return bd->props.brightness;
}
=20
-static struct backlight_ops aty128_bl_data =3D {
+static const struct backlight_ops aty128_bl_data =3D {
.get_brightness =3D aty128_bl_get_brightness,
.update_status =3D aty128_bl_update_status,
};
diff --git a/drivers/video/aty/atyfb_base.c b/drivers/video/aty/atyfb_base.c
index 1ddeb4c..fc4e221 100644
--- a/drivers/video/aty/atyfb_base.c
+++ b/drivers/video/aty/atyfb_base.c
@@ -2225,7 +2225,7 @@ static int aty_bl_get_brightness(struct backlight_dev=
ice *bd)
return bd->props.brightness;
}
=20
-static struct backlight_ops aty_bl_data =3D {
+static const struct backlight_ops aty_bl_data =3D {
.get_brightness =3D aty_bl_get_brightness,
.update_status =3D aty_bl_update_status,
};
diff --git a/drivers/video/aty/radeon_backlight.c b/drivers/video/aty/radeo=
n_backlight.c
index 1a056ad..221bd6a 100644
--- a/drivers/video/aty/radeon_backlight.c
+++ b/drivers/video/aty/radeon_backlight.c
@@ -127,7 +127,7 @@ static int radeon_bl_get_brightness(struct backlight_de=
vice *bd)
return bd->props.brightness;
}
=20
-static struct backlight_ops radeon_bl_data =3D {
+static const struct backlight_ops radeon_bl_data =3D {
.get_brightness =3D radeon_bl_get_brightness,
.update_status =3D radeon_bl_update_status,
};
diff --git a/drivers/video/bf54x-lq043fb.c b/drivers/video/bf54x-lq043fb.c
index e49ae5e..db4e6f7 100644
--- a/drivers/video/bf54x-lq043fb.c
+++ b/drivers/video/bf54x-lq043fb.c
@@ -463,7 +463,7 @@ static int bl_get_brightness(struct backlight_device *b=
d)
return 0;
}
=20
-static struct backlight_ops bfin_lq043fb_bl_ops =3D {
+static const struct backlight_ops bfin_lq043fb_bl_ops =3D {
.get_brightness =3D bl_get_brightness,
};
=20
diff --git a/drivers/video/bfin-t350mcqb-fb.c b/drivers/video/bfin-t350mcqb=
-fb.c
index 2549c53..bc204c6 100644
--- a/drivers/video/bfin-t350mcqb-fb.c
+++ b/drivers/video/bfin-t350mcqb-fb.c
@@ -381,7 +381,7 @@ static int bl_get_brightness(struct backlight_device *b=
d)
return 0;
}
=20
-static struct backlight_ops bfin_lq043fb_bl_ops =3D {
+static const struct backlight_ops bfin_lq043fb_bl_ops =3D {
.get_brightness =3D bl_get_brightness,
};
=20
diff --git a/drivers/video/nvidia/nv_backlight.c b/drivers/video/nvidia/nv_=
backlight.c
index 443e3c8..c443d6a 100644
--- a/drivers/video/nvidia/nv_backlight.c
+++ b/drivers/video/nvidia/nv_backlight.c
@@ -87,7 +87,7 @@ static int nvidia_bl_get_brightness(struct backlight_devi=
ce *bd)
return bd->props.brightness;
}
=20
-static struct backlight_ops nvidia_bl_ops =3D {
+static const struct backlight_ops nvidia_bl_ops =3D {
.get_brightness =3D nvidia_bl_get_brightness,
.update_status =3D nvidia_bl_update_status,
};
diff --git a/drivers/video/omap2/displays/panel-taal.c b/drivers/video/omap=
2/displays/panel-taal.c
index 1f01dfc..a5f7f82 100644
--- a/drivers/video/omap2/displays/panel-taal.c
+++ b/drivers/video/omap2/displays/panel-taal.c
@@ -313,7 +313,7 @@ static int taal_bl_get_intensity(struct backlight_devic=
e *dev)
return 0;
}
=20
-static struct backlight_ops taal_bl_ops =3D {
+static const struct backlight_ops taal_bl_ops =3D {
.get_brightness =3D taal_bl_get_intensity,
.update_status =3D taal_bl_update_status,
};
diff --git a/drivers/video/riva/fbdev.c b/drivers/video/riva/fbdev.c
index d94c57f..912984c 100644
--- a/drivers/video/riva/fbdev.c
+++ b/drivers/video/riva/fbdev.c
@@ -331,7 +331,7 @@ static int riva_bl_get_brightness(struct backlight_devi=
ce *bd)
return bd->props.brightness;
}
=20
-static struct backlight_ops riva_bl_ops =3D {
+static const struct backlight_ops riva_bl_ops =3D {
.get_brightness =3D riva_bl_get_brightness,
.update_status =3D riva_bl_update_status,
};
--=20
1.6.4.4
^ permalink raw reply related
* Re: [Patch 1/1] PPC64-HWBKPT: Implement hw-breakpoints for PPC64
From: Frederic Weisbecker @ 2010-02-21 1:01 UTC (permalink / raw)
To: K.Prasad
Cc: Michael Neuling, Benjamin Herrenschmidt, shaggy,
Mahesh Salgaonkar, Will Deacon, David Gibson, linuxppc-dev,
Alan Stern, paulus, Roland McGrath
In-Reply-To: <20100215055914.GA6017@in.ibm.com>
On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
> +struct arch_hw_breakpoint {
> + u8 len; /* length of the target symbol */
> + int type;
> + char *name; /* Contains name of the symbol to set bkpt */
> + unsigned long address;
> +};
I don't think it's a good idea to integrate the name of
the target. This is something that should be done in a higher
level, not in an arch backend.
We don't even need to store it anywhere as we can resolve
back an address easily. Symbol awareness is not something
the hardware breakpoint should care about, neither in the
arch nor the generic level.
Also, do you think addr/len/type is enough to abstract out
any ppc breakpoints?
This looks enough to me to express range breakpoints and
simple breakpoints. But what about value comparison?
(And still, there may be other trickier implementations
I don't know in ppc).
> +
> +#include <linux/kdebug.h>
> +#include <asm/reg.h>
> +#include <asm/system.h>
> +
> +/* Total number of available HW breakpoint registers */
> +#define HBP_NUM 1
Looking at the G2 PowerPc implementation, DABR and DABR2 can either
express two different watchpoints or one range watchpoint.
There are also IABR and IABR2 for instruction breakpoints that
follow the same above scheme. I'm not sure we can abstract that
using a constant max linear number of resources.
> +static inline void hw_breakpoint_disable(void)
> +{
> + set_dabr(0);
> +}
So, this is only about data breakpoints?
> + /*
> + * As a policy, the callback is invoked in a 'trigger-after-execute'
> + * fashion
> + */
> + (bp->overflow_handler)(bp, 0, NULL, regs);
Why are you calling this explicitly instead of using the perf_bp_event()
thing? This looks like it won't work with perf as the event won't
be recorded by perf.
> +void ptrace_triggered(struct perf_event *bp, int nmi,
> + struct perf_sample_data *data, struct pt_regs *regs)
> +{
> + struct perf_event_attr attr;
> +
> + /*
> + * Disable the breakpoint request here since ptrace has defined a
> + * one-shot behaviour for breakpoint exceptions in PPC64.
> + * The SIGTRAP signal is generated automatically for us in do_dabr().
> + * We don't have to do anything about that here
> + */
Oh, why does ptrace use a one-shot behaviour in ppc? Breakpoints
only trigger once?
> + if (bp) {
> + attr = bp->attr;
> + attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
> +
> + switch (data & (DABR_DATA_WRITE | DABR_DATA_READ)) {
> + case DABR_DATA_READ:
> + attr.bp_type = HW_BREAKPOINT_R;
> + break;
> + case DABR_DATA_WRITE:
> + attr.bp_type = HW_BREAKPOINT_W;
> + break;
> + case (DABR_DATA_WRITE | DABR_DATA_READ):
> + attr.bp_type = HW_BREAKPOINT_R | HW_BREAKPOINT_W;
> + break;
> + }
> + ret = modify_user_hw_breakpoint(bp, &attr);
> + if (ret)
> + return ret;
> + thread->ptrace_bps[0] = bp;
> + thread->dabr = data;
> + return 0;
> + }
> +
> + /* Create a new breakpoint request if one doesn't exist already */
> + hw_breakpoint_init(&attr);
> + attr.bp_addr = data & ~HW_BREAKPOINT_ALIGN;
> + switch (data & (DABR_DATA_WRITE | DABR_DATA_READ)) {
> + case DABR_DATA_READ:
> + attr.bp_type = HW_BREAKPOINT_R;
> + break;
> + case DABR_DATA_WRITE:
> + attr.bp_type = HW_BREAKPOINT_W;
> + break;
> + case (DABR_DATA_WRITE | DABR_DATA_READ):
> + attr.bp_type = HW_BREAKPOINT_R | HW_BREAKPOINT_W;
> + break;
> + }
> + thread->ptrace_bps[0] = bp = register_user_hw_breakpoint(&attr,
> + ptrace_triggered, task);
> + if (IS_ERR(bp)) {
> + thread->ptrace_bps[0] = NULL;
> + return PTR_ERR(bp);
> + }
> +
> +#endif /* CONFIG_PPC64 */
This looks fine for basic breakpoints. And this can probably be
improved to integrate ranges.
But I think we did something wrong with the generic breakpoint
interface. We are translating the arch values to generic
attributes. Then this all will be translated back to arch
values.
Having generic attributes is necessary for any perf event
use from userspace. But it looks like a waste for ptrace
that already gives us arch values. And the problem
is the same for x86.
So I think we should implement a register_ptrace_breakpoint()
that doesn't take perf_event_attr but specific arch informations,
so that we don't need to pass through a generic conversion, which:
- is wasteful
- won't be able to express 100% of any arch capabilities. We
can certainly express most arch breakpoints features through
the generic interface, but not all of them (given how tricky
the data value comparison features can be)
I will rework that during the next cycle.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/1] NDFC: add support for alternate ECC format for ndfc
From: Sean MacLennan @ 2010-02-21 1:11 UTC (permalink / raw)
To: Feng Kan; +Cc: Feng Kan, linuxppc-dev, linux-mtd
In-Reply-To: <1266534678-30293-1-git-send-email-fkan@amcc.com>
On Thu, 18 Feb 2010 15:11:18 -0800
Feng Kan <fkan@amcc.com> wrote:
> This is to lock down the ordering in the correction routine against
> the calculate routine. Otherwise, incorrect define would cause ECC
> errors.
Did you actually find a 44x PPC core that is not NAND_ECC_SMS format?
Cheers,
Sean
^ permalink raw reply
* Re: [-next Feb 18] PowerPC boot failure (Unknowd ADD relocation :26)
From: Michael Neuling @ 2010-02-21 20:35 UTC (permalink / raw)
To: Sachin Sant; +Cc: Linux/PPC Development, linux-next, Stephen Rothwell
In-Reply-To: <4B7E118C.7060208@in.ibm.com>
In message <4B7E118C.7060208@in.ibm.com> you wrote:
> This is a multi-part message in MIME format.
> --------------020408070005080107030800
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
> Yesterday's next failed to boot on various powerpc boxes
> with following error :
>
> NET: Registered protocol family 15
> registered taskstats version 1
> Freeing unused kernel memory: 640k freed
> doing fast boot
> scsi_mod: Unknown ADD relocation: 26
> WARNING: Error inserting scsi_mod (/lib/modules/2.6.33-rc8-autotest-next-2010
0218/kernel/drivers/scsi/scsi_mod.ko): Invalid module format
> scsi_tgt: Unknown symbol scsi_release_buffers
> scsi_tgt: Unknown symbol scsi_host_put
> scsi_tgt: Unknown symbol __scsi_put_command
> scsi_tgt: Unknown symbol scsi_host_lookup
> scsi_tgt: Unknown symbol __scsi_get_command
> scsi_tgt: Unknown symbol scsi_init_io
> scsi_tgt: Unknown symbol __scsi_alloc_queue
>
> and many more such modules related errors.
> I have attached the boot log here.
Can you attached the .config as well for this??
Mikey
>
> Next Feb 17th was OK. Haven't yet tried the git bisect.
> Will try that out today.
>
> Thanks
> -Sachin
>
>
> --
>
> ---------------------------------
> Sachin Sant
> IBM Linux Technology Center
> India Systems and Technology Labs
> Bangalore, India
> ---------------------------------
>
>
> --------------020408070005080107030800
> Content-Type: text/plain;
> name="boot-log"
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline;
> filename="boot-log"
>
> Using 00825420 bytes for initrd buffer
> Please wait, loading kernel...
> Allocated 00f00000 bytes for kernel @ 00d00000
> Elf64 kernel loaded...
> Loading ramdisk...
> ramdisk loaded 00825420 @ 034d0000
> OF stdout device is: /vdevice/vty@30000000
> Preparing to boot Linux version 2.6.33-rc8-autotest-next-20100218 (root@llm62
) (gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Thu
Feb 18 17:49:40 IST 2010
> Max number of cores passed to firmware: 0x0000000000000200
> Calling ibm,client-architecture-support... done
> command line: root=/dev/sda5 IDENT=1266496633
> memory layout at init:
> memory_limit : 0000000000000000 (16 MB aligned)
> alloc_bottom : 0000000003d00000
> alloc_top : 0000000008000000
> alloc_top_hi : 0000000008000000
> rmo_top : 0000000008000000
> ram_top : 0000000008000000
> instantiating rtas at 0x00000000074e0000... done
> boot cpu hw idx 0000000000000000
> starting cpu hw idx 0000000000000002... done
> copying OF device tree...
> Building dt strings...
> Building dt structure...
> Device tree strings 0x0000000003d10000 -> 0x0000000003d115fa
> Device tree struct 0x0000000003d20000 -> 0x0000000003d40000
> Calling quiesce...
> returning from prom_init
> Using pSeries machine description
> Using 1TB segments
> Found initrd at 0xc0000000034d0000:0xc000000003cf5420
> bootconsole [udbg0] enabled
> Partition configured for 4 cpus.
> CPU maps initialized for 2 threads per core
> Starting Linux PPC64 #1 SMP Thu Feb 18 17:49:40 IST 2010
> -----------------------------------------------------
> ppc64_pft_size = 0x1a
> physicalMemorySize = 0x100000000
> htab_hash_mask = 0x7ffff
> -----------------------------------------------------
> Initializing cgroup subsys cpuset
> Initializing cgroup subsys cpu
> Linux version 2.6.33-rc8-autotest-next-20100218 (root@llm62) (gcc version 4.3
.2 [gcc-4_3-branch revision 141291] (SUSE Linux) ) #1 SMP Thu Feb 18 17:49:40 I
ST 2010
> [boot]0012 Setup Arch
> EEH: No capable adapters found
> PPC64 nvram contains 15360 bytes
> Zone PFN ranges:
> DMA 0x00000000 -> 0x00010000
> Normal 0x00010000 -> 0x00010000
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
> 1: 0x00000000 -> 0x00010000
> Could not find start_pfn for node 0
> [boot]0015 Setup Done
> PERCPU: Embedded 2 pages/cpu @c000000000f00000 s89768 r0 d41304 u262144
> pcpu-alloc: s89768 r0 d41304 u262144 alloc=1*1048576
> pcpu-alloc: [0] 0 1 2 3
> Built 2 zonelists in Node order, mobility grouping on. Total pages: 65480
> Policy zone: DMA
> Kernel command line: root=/dev/sda5 IDENT=1266496633
> PID hash table entries: 4096 (order: -1, 32768 bytes)
> freeing bootmem node 1
> Memory: 4142272k/4194304k available (9280k kernel code, 52032k reserved, 2624
k data, 2287k bss, 640k init)
> Hierarchical RCU implementation.
> RCU-based detection of stalled CPUs is enabled.
> NR_IRQS:512 nr_irqs:512
> [boot]0020 XICS Init
> [boot]0021 XICS Done
> clocksource: timebase mult[7d0000] shift[22] registered
> Console: colour dummy device 80x25
> console [hvc0] enabled, bootconsole disabled
> console [hvc0] enabled, bootconsole disabled
> allocated 2621440 bytes of page_cgroup
> please try 'cgroup_disable=memory' option if you don't want memory cgroups
> Security Framework initialized
> SELinux: Disabled at boot.
> Dentry cache hash table entries: 524288 (order: 6, 4194304 bytes)
> Inode-cache hash table entries: 262144 (order: 5, 2097152 bytes)
> Mount-cache hash table entries: 4096
> Initializing cgroup subsys ns
> Initializing cgroup subsys cpuacct
> Initializing cgroup subsys memory
> Initializing cgroup subsys devices
> Initializing cgroup subsys freezer
> Initializing cgroup subsys blkio
> Processor 1 found.
> Processor 2 found.
> Processor 3 found.
> Brought up 4 CPUs
> devtmpfs: initialized
> NET: Registered protocol family 16
> IBM eBus Device Driver
> POWER6 performance monitor hardware support registered
> PCI: Probing PCI hardware
> bio: create slab <bio-0> at 0
> vgaarb: loaded
> usbcore: registered new interface driver usbfs
> usbcore: registered new interface driver hub
> usbcore: registered new device driver usb
> Switching to clocksource timebase
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 2, 262144 bytes)
> TCP established hash table entries: 131072 (order: 5, 2097152 bytes)
> TCP bind hash table entries: 65536 (order: 4, 1048576 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> UDP hash table entries: 2048 (order: 0, 65536 bytes)
> UDP-Lite hash table entries: 2048 (order: 0, 65536 bytes)
> NET: Registered protocol family 1
> Unpacking initramfs...
> Freeing initrd memory: 8341k freed
> IOMMU table initialized, virtual merging enabled
> audit: initializing netlink socket (disabled)
> type=2000 audit(1266496684.180:1): initialized
> rcu-torture:--- Start of test: nreaders=8 nfakewriters=4 stat_interval=0 verb
ose=0 test_no_idle_hz=0 shuffle_interval=3 stutter=5 irqreader=1 fqs_duration=0
fqs_holdoff=0 fqs_stutter=3
> HugeTLB registered 16 MB page size, pre-allocated 0 pages
> HugeTLB registered 16 GB page size, pre-allocated 0 pages
> VFS: Disk quotas dquot_6.5.2
> Dquot-cache hash table entries: 8192 (order 0, 65536 bytes)
> msgmni has been set to 8104
> alg: No test for stdrng (krng)
> Block layer SCSI generic (bsg) driver version 0.4 loaded (major 254)
> io scheduler noop registered
> io scheduler deadline registered
> io scheduler cfq registered (default)
> pci_hotplug: PCI Hot Plug PCI Core version: 0.5
> pciehp: PCI Express Hot Plug Controller Driver version: 0.4
> rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
> Generic RTC Driver v1.07
> Serial: 8250/16550 driver, 4 ports, IRQ sharing disabled
> pmac_zilog: 0.6 (Benjamin Herrenschmidt <benh@kernel.crashing.org>)
> Uniform Multi-Platform E-IDE driver
> ide-gd driver 1.18
> ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
> ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
> mice: PS/2 mouse device common for all mice
> EDAC MC: Ver: 2.1.0 Feb 18 2010
> usbcore: registered new interface driver hiddev
> usbcore: registered new interface driver usbhid
> usbhid: USB HID core driver
> TCP cubic registered
> NET: Registered protocol family 15
> registered taskstats version 1
> Freeing unused kernel memory: 640k freed
> doing fast boot
> scsi_mod: Unknown ADD relocation: 26
> WARNING: Error inserting scsi_mod (/lib/modules/2.6.33-rc8-autotest-next-2010
0218/kernel/drivers/scsi/scsi_mod.ko): Invalid module format
> scsi_tgt: Unknown symbol scsi_release_buffers
> scsi_tgt: Unknown symbol scsi_host_put
> scsi_tgt: Unknown symbol __scsi_put_command
> scsi_tgt: Unknown symbol scsi_host_lookup
> scsi_tgt: Unknown symbol __scsi_get_command
> scsi_tgt: Unknown symbol scsi_init_io
> scsi_tgt: Unknown symbol __scsi_alloc_queue
> WARNING: Error inserting scsi_tgt (/lib/modules/2.6.33-rc8-autotest-next-2010
0218/kernel/drivers/scsi/scsi_tgt.ko): Unknown symbol in module, or unknown par
ameter (see dmesg)
> scsi_transport_srp: Unknown symbol scsi_tgt_it_nexus_destroy
> scsi_transport_srp: Unknown symbol scsi_tgt_it_nexus_create
> scsi_transport_srp: Unknown symbol scsi_is_host_device
> WARNING: Error inserting scsi_transport_srp (/lib/modules/2.6.33-rc8-autotest
-next-20100218/kernel/drivers/scsi/scsi_transport_srp.ko): Unknown symbol in mo
dule, or unknown parameter (see dmesg)
> ibmvscsic: Unknown symbol scsi_block_requests
> ibmvscsic: Unknown symbol scsi_scan_host
> ibmvscsic: Unknown symbol scsi_dma_unmap
> ibmvscsic: Unknown symbol scsi_add_host_with_dma
> ibmvscsic: Unknown symbol scsi_host_put
> ibmvscsic: Unknown symbol srp_release_transport
> ibmvscsic: Unknown symbol scsi_dma_map
> ibmvscsic: Unknown symbol srp_remove_host
> ibmvscsic: Unknown symbol srp_attach_transport
> ibmvscsic: Unknown symbol scsi_unblock_requests
> ibmvscsic: Unknown symbol scsi_remove_host
> ibmvscsic: Unknown symbol srp_rport_add
> ibmvscsic: Unknown symbol scsi_adjust_queue_depth
> ibmvscsic: Unknown symbol scsi_host_alloc
> FATAL: Error inserting ibmvscsic (/lib/modules/2.6.33-rc8-autotest-next-20100
218/kernel/drivers/scsi/ibmvscsi/ibmvscsic.ko): Unknown symbol in module, or un
known parameter (see dmesg)
> Creating device nodes with udev
> udevd version 128 started
> scsi_mod: Unknown ADD relocation: 26
> scsi_tgt: Unknown symbol scsi_release_buffers
> scsi_tgt: Unknown symbol scsi_host_put
> scsi_tgt: Unknown symbol __scsi_put_command
> scsi_tgt: Unknown symbol scsi_host_lookup
> scsi_tgt: Unknown symbol __scsi_get_command
> scsi_tgt: Unknown symbol scsi_init_io
> scsi_tgt: Unknown symbol __scsi_alloc_queue
> scsi_transport_srp: Unknown symbol scsi_tgt_it_nexus_destroy
> scsi_transport_srp: Unknown symbol scsi_tgt_it_nexus_create
> scsi_transport_srp: Unknown symbol scsi_is_host_device
> ibmvscsic: Unknown symbol scsi_block_requests
> ibmvscsic: Unknown symbol scsi_scan_host
> ibmvscsic: Unknown symbol scsi_dma_unmap
> ibmvscsic: Unknown symbol scsi_add_host_with_dma
> ibmvscsic: Unknown symbol scsi_host_put
> ibmvscsic: Unknown symbol srp_release_transport
> ibmvscsic: Unknown symbol scsi_dma_map
> ibmvscsic: Unknown symbol srp_remove_host
> ibmvscsic: Unknown symbol srp_attach_transport
> ibmvscsic: Unknown symbol scsi_unblock_requests
> ibmvscsic: Unknown symbol scsi_remove_host
> ibmvscsic: Unknown symbol srp_rport_add
> ibmvscsic: Unknown symbol scsi_adjust_queue_depth
> ibmvscsic: Unknown symbol scsi_host_alloc
> Boot logging started on /dev/hvc0(/dev/console) at Thu Feb 18 12:38:04 2010
> resume device not found (ignoring)
> Waiting for device /dev/sda5 to appear: ..............................Could n
ot find /dev/sda5.
> Want me to fall back to /dev/sda5? (Y/n)
> -- 0:conmux-control -- time-stamp -- Feb/18/10 4:41:54 --
> -- 0:conmux-control -- time-stamp -- Feb/18/10 6:00:16 --
> (user:ssant@in.ibm.com) connected
>
> Waiting for device /dev/sda5 to appear: ..............................not fou
nd -- exiting to /bin/sh
>
>
> --------------020408070005080107030800
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> --------------020408070005080107030800--
>
^ permalink raw reply
* Re: [-next Feb 18] PowerPC boot failure (Unknowd ADD relocation :26)
From: Sachin Sant @ 2010-02-22 4:59 UTC (permalink / raw)
To: Michael Neuling; +Cc: Linux/PPC Development, linux-next, Stephen Rothwell
In-Reply-To: <4B7E118C.7060208@in.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1273 bytes --]
Sachin Sant wrote:
> Yesterday's next failed to boot on various powerpc boxes
> with following error :
>
> NET: Registered protocol family 15
> registered taskstats version 1
> Freeing unused kernel memory: 640k freed
> doing fast boot
> scsi_mod: Unknown ADD relocation: 26
> WARNING: Error inserting scsi_mod
> (/lib/modules/2.6.33-rc8-autotest-next-20100218/kernel/drivers/scsi/scsi_mod.ko):
> Invalid module format
> scsi_tgt: Unknown symbol scsi_release_buffers
> scsi_tgt: Unknown symbol scsi_host_put
> scsi_tgt: Unknown symbol __scsi_put_command
> scsi_tgt: Unknown symbol scsi_host_lookup
> scsi_tgt: Unknown symbol __scsi_get_command
> scsi_tgt: Unknown symbol scsi_init_io
> scsi_tgt: Unknown symbol __scsi_alloc_queue
>
> and many more such modules related errors.
> I have attached the boot log here.
>
> Next Feb 17th was OK. Haven't yet tried the git bisect.
> Will try that out today.
Git bisect isn't giving me reliable results. Sometimes
the machine boots fine after reverting few patches, but
the very next boot with same kernel fails.
Have attached the .config(.gz)
thanks
-Sachin
--
---------------------------------
Sachin Sant
IBM Linux Technology Center
India Systems and Technology Labs
Bangalore, India
---------------------------------
[-- Attachment #2: config_next_19.gz --]
[-- Type: application/x-gzip, Size: 20110 bytes --]
^ 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