Currently when we do a packet flood to the Ethernet port, the console
reports error every time when a packet is dropped. This is too
redundant and cost performance. Remove message for this type of event.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
drivers/net/fs_enet/mac-fcc.c |2 +-
1 f
Initialize base and size of SEC memory region and bus priority for SEC.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/immap_cpm2.h |7 +--
arch/powerpc/platforms/82xx/mpc8272_ads.c |1 +
arch/powerpc/platforms/82xx/pq2.c | 19 +++
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc836x_mds.dts | 15 ++-
arch/powerpc/platforms/83xx/mpc836x_mds.c | 19 -
arch/powerpc/platforms/83xx/mpc83xx.h |1 +
arch/powerpc/platforms/83xx/usb.c | 67 +
4
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8272ads.dts |8
arch/powerpc/platforms/82xx/mpc8272_ads.c | 25 +
arch/powerpc/platforms/82xx/pq2ads.h |3 +++
3 files changed, 36 insertions(+), 0 deletions(-)
diff --git
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/include/asm/immap_cpm2.h |9 +++--
arch/powerpc/include/asm/immap_qe.h |9 +++--
2 files changed, 6 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/include/asm/immap_cpm2.h
b/arch/powerpc/include/asm/immap_cpm
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/cpm2.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/cpm2.c b/arch/powerpc/sysdev/cpm2.c
index f1c3395..021480e 100644
--- a/arch/powerpc/sysdev/cpm2.c
+++ b/arch/powerpc/sysdev/cpm2.c
Make the flash size 8M to be consistent with the module comes with board.
Add predefined partitions for the flash. Add ethernet port aliases.
Signed-off-by: Li Yang <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8272ads.dts | 38 +
1 files changed, 33 insertio
Hello Kumar,
On Wed Jul 2 19:58:03 EST 2008 Heiko Schocher wrote:
>On Wednesday 02 July 2008, Kumar Gala wrote:
>> Please point out any patches that have been posted but havent made it
>> into a git tree related to Freescale chips.
>
> Here are 2 patches that I'd like to see in 2.6.27. They haven'
On Tue, 2008-08-05 at 17:16 +1000, Benjamin Herrenschmidt wrote:
> On Tue, 2008-08-05 at 16:47 +1200, Paul Collins wrote:
> > It's about four years old. It was in storage for about six months and I
> > got it repaired a few weeks ago (display cable and inverter). The sort
> > of crazy crap I've b
On Wed, Aug 6, 2008 at 12:32 AM, David Miller <[EMAIL PROTECTED]> wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
> Date: Wed, 06 Aug 2008 00:02:44 -0600
>
>> of_lookup_stdout() is useful for figuring out what device to use as output
>> for early boot progress messages. It returns the node pointed
On Wed, Aug 6, 2008 at 12:14 AM, Michael Ellerman
<[EMAIL PROTECTED]> wrote:
> On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
>> From: Grant Likely <[EMAIL PROTECTED]>
>>
>> of_lookup_stdout() is useful for figuring out what device to use as output
>> for early boot progress messages. It r
From: Grant Likely <[EMAIL PROTECTED]>
Date: Wed, 06 Aug 2008 00:02:44 -0600
> of_lookup_stdout() is useful for figuring out what device to use as output
> for early boot progress messages. It returns the node pointed to by the
> linux,stdout-path property in the chosen node.
>
> Signed-off-by:
On Wed, 2008-08-06 at 00:02 -0600, Grant Likely wrote:
> From: Grant Likely <[EMAIL PROTECTED]>
>
> of_lookup_stdout() is useful for figuring out what device to use as output
> for early boot progress messages. It returns the node pointed to by the
> linux,stdout-path property in the chosen node.
From: Grant Likely <[EMAIL PROTECTED]>
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
arch/powerpc/Kconfig.debug | 11 +++
arch/powerpc/kernel/udbg.c |2
arch/powerpc/platforms/52xx/lite5200.c |6 +
arch/powerpc/platforms/52xx/mpc5200_sim
From: Grant Likely <[EMAIL PROTECTED]>
of_lookup_stdout() is useful for figuring out what device to use as output
for early boot progress messages. It returns the node pointed to by the
linux,stdout-path property in the chosen node.
Signed-off-by: Grant Likely <[EMAIL PROTECTED]>
---
drivers/o
From: Grant Likely <[EMAIL PROTECTED]>
ioremap_bat() is useful for things like mapping SoC internally memory mapped
register and early text because it allows mappings to devices to be setup
early in the boot process where they are needed, and the mappings persist
after the MMU is configured.
With
Here is my attempt to make BAT allocations dynamic instead of hard coded.
The first patch changes setbat() to dynamically assign BATs instead of requiring
the caller to select a BAT on its own.
A primary user of setbat is mmu_mapin_ram() which used to hard code BATs
2 and 3 for mapping as much of
This changes the way we make the boot wrapper position-independent.
Before we just added the offset (the difference between runtime
address and link address) to each entry in the .got2 section. That
doesn't relocate pointer values in initialized variables and arrays.
Instead we now link the bootw
On Tue, 2008-08-05 at 20:55 -0600, miltonm wrote:
> - Original Message Follows -
> From: Michael Ellerman <[EMAIL PROTECTED]>
> To: Paul Mackerras <[EMAIL PROTECTED]>
> Cc: , Milton Miller
> <[EMAIL PROTECTED]>, Segher Boessenkool
> <[EMAIL PROTECTED]>
> Subject: [PATCH] powerpc: EOI spurio
As well as fdt_subnode_offset(), libfdt includes an
fdt_subnode_offset_namelen() function that takes the subnode name to
look up not as a NUL-terminated string, but as a string with an
explicit length. This can be useful when the caller has the name as
part of a longer string, such as a full path.
Hi John,
[From further in the discussion, this may no longer be relevant ...]
On Tue, 5 Aug 2008 14:13:37 -0600 John Rigby <[EMAIL PROTECTED]> wrote:
>
> - soc = of_find_node_by_type(NULL, "soc");
> + /*
> + * First look for an immr alias
> + */
> + np = of_find_node_by_nam
- Original Message Follows -
From: Michael Ellerman <[EMAIL PROTECTED]>
To: Paul Mackerras <[EMAIL PROTECTED]>
Cc: , Milton Miller
<[EMAIL PROTECTED]>, Segher Boessenkool
<[EMAIL PROTECTED]>
Subject: [PATCH] powerpc: EOI spurious irqs during boot so
they can be reenabled later
Date: Wed, 6
Jeremy Kerr wrote:
Hi Kevin,
/*
* Turn r3 (range) into a rotate count for the selected
range. * 0 -> 23, 1 -> 31
*/
__asm__ __volatile__ ( "slwi %0,%0,3\n"
"addi %0,%0,23\n"
"rlwnm %0,%1,%0,30,31
In the xics code, if we receive an irq during boot that hasn't been setup
yet - ie. we have no reverse mapping for it - we mask the irq so we don't
hear from it again.
Later on if someone request_irq()'s that irq, we'll unmask it but it will
still never fire. This is because we never EOI'ed the ir
Michael Ellerman wrote:
On Tue, 2008-08-05 at 12:26 -0700, Kevin Diggs wrote:
Chris Friesen wrote:
Kevin Diggs wrote:
I have the following near the top of my cpufreq driver target
routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone
On Tue, 2008-08-05 at 18:48 +0200, Segher Boessenkool wrote:
> > So when we receive a spurious irq, EOI it, and then mask it.
>
> What happens when a new IRQ arrives on the interrupt controller
> between these EOI and mask calls? Should you instead first mask
> it, and only then EOI it? Or doesn
Hi Kevin,
> /*
> * Turn r3 (range) into a rotate count for the selected
> range. * 0 -> 23, 1 -> 31
> */
> __asm__ __volatile__ ( "slwi %0,%0,3\n"
> "addi %0,%0,23\n"
> "rlwnm %0,%1,%0,30,31\n"
On Tue, 2008-08-05 at 17:20 -0700, Kevin Diggs wrote:
> Hi,
>
> thats bad right? Because the "addi 0, 0, 23" will not work as expected
> because of the "special property" of r0. FYI: The first three lines
> after the "#APP" are from a similar function get_PLL_ratio().
>
> Is there a way
Hi,
If I have:
inline unsigned int get_PLL_range(unsigned int range, unsigned int
config)
{
unsigned int ret;
/*
* Turn r3 (range) into a rotate count for the selected range.
* 0 -> 23, 1 -> 31
*/
__asm__ __volatile__ ( "slwi %0,%0,3\n"
On Tue, Aug 05, 2008 at 04:19:44PM -0500, Scott Wood wrote:
> Grant Likely wrote:
>> But finding nodes that meet a criteria *is* what compatible is for and
>> there is precedence for it. All u-boot platforms are finding the node
>> by path right now, and so all of them need to be changed. Changin
Benjamin Herrenschmidt wrote:
>> arch/powerpc/platfroms/ps3/htab.c:ps3_hpte_updatepp() uses `htab[slot].v'.
>
> Ok, that leaves us with 2 options:
>
> - Change ps3_hpte_updatepp() to not read from the hash table via that
> mapping (ie, do you have an LV1 call to read an HPTE ? Do you measure
> a
This effects the U3 MSI code as well as the PASEMI MSI code. We keep
some of the MPIC routines as helpers, and also the U3 best-guess
reservation logic. The rest is replaced by the generic code.
And a few printk format changes due to hwirq type change.
Signed-off-by: Michael Ellerman <[EMAIL PROT
This is 90% straight forward, although we have to change a few
printk format strings as well because of the change in type of hwirq.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_msi.c | 103 ++---
arch/powerpc/sysdev/fsl_msi.
There are now two almost identical implementations of an MSI bitmap
allocator, one in mpic_msi.c and the other in fsl_msi.c.
Merge them together and put the result in msi_bitmap.c. Some of the
MPIC bits will remain to provide a nicer interface for the MPIC users.
In the process we fix two buglets
The FSL MSI code keeps a pointer to the of_node from the device
it represents. However it also has an irq_host, which contains
a pointer to the of_node, so use that one instead.
Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_msi.c | 12 +---
arch/powerpc
On Tue, 2008-08-05 at 12:26 -0700, Kevin Diggs wrote:
> Chris Friesen wrote:
> > Kevin Diggs wrote:
> >> I have the following near the top of my cpufreq driver target
> >> routine:
> >>
> >> while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
> >> /*
> >> * Som
Thanks Josh, I just came to the conclusion it was busted somehow in the
mainline after repeating it there.
-- John
> -Original Message-
> From: Josh Boyer [mailto:[EMAIL PROTECTED] On Behalf Of Josh Boyer
> Sent: Tuesday, August 05, 2008 4:49 PM
> To: John Linn
> Cc: linuxppc-dev@ozlabs.o
On Tue, 2008-08-05 at 15:37 -0600, John Linn wrote:
> I’m trying to debug some Kconfig problems and am looking for a way to
> get more debug output.
>
>
>
> I have used KBUILD_VERBOSE=1 on the command line and it didn’t help
> much.
>
>
>
> I’m seeing an issue with creating a new defconfig
Scott Wood wrote:
John Rigby wrote:
I would like to use mpc83xx_add_bridge for 5121. This is why I
moved it to fsl_pci.c. It currently uses get_immrbase and adds
0x8300 and 0x8304 to it to pass to setup_indirect_pci as the
cfg_addr, and cfg_data addresses.
I'm more than willing
I'm trying to debug some Kconfig problems and am looking for a way to
get more debug output.
I have used KBUILD_VERBOSE=1 on the command line and it didn't help
much.
I'm seeing an issue with creating a new defconfig file for a board. I
get the .config created, then copy it to a defconfig,
John Rigby wrote:
I would like to use mpc83xx_add_bridge for 5121. This is why I
moved it to fsl_pci.c. It currently uses get_immrbase and adds
0x8300 and 0x8304 to it to pass to setup_indirect_pci as the
cfg_addr, and cfg_data addresses.
I'm more than willing to change mpc83xx_
Grant Likely wrote:
But finding nodes that meet a criteria *is* what compatible is for and
there is precedence for it. All u-boot platforms are finding the node
by path right now, and so all of them need to be changed. Changing
them to find by compatible that is set per-board or per-SoC makes
c
Uncle!
U-boot:
The 5121 currently fixes up the soc's bus-frequency node with a hard
coded path.
I'll leave it that way.
Kernel:
I would like to use mpc83xx_add_bridge for 5121. This is why I
moved it to fsl_pci.c. It currently uses get_immrbase and adds
0x8300 and 0x8304 to
On Tue, Aug 5, 2008 at 3:08 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> Grant Likely wrote:
>>
>> Is it not sufficient to search the tree for a node with the
>> -immr compatible value? I don't think this is the intended use
>> case of aliases.
>
> That get's really annoying in code that is meant t
Grant Likely wrote:
Is it not sufficient to search the tree for a node with the
-immr compatible value? I don't think this is the intended use
case of aliases.
That get's really annoying in code that is meant to deal with multiple
chips. I don't think finding the network or serial node that
On Tue, Aug 5, 2008 at 2:49 PM, Scott Wood <[EMAIL PROTECTED]> wrote:
> Arnd Bergmann wrote:
>>
>> On Tuesday 05 August 2008, John Rigby wrote:
>>>
>>> This will allow the eventual removal of device_type = "soc"
>>> properties in soc nodes.
>>
>> Stupid question, but why not remove immrbase instead
Oops, forgot to add devicetree-discuss to the cc: list
g.
On Tue, Aug 5, 2008 at 3:05 PM, Grant Likely <[EMAIL PROTECTED]> wrote:
> On Tue, Aug 5, 2008 at 2:13 PM, John Rigby <[EMAIL PROTECTED]> wrote:
>> So get_immrbase can function without a device_type = "soc"
>> property in the soc node.
>>
>
On Tue, Aug 5, 2008 at 2:13 PM, John Rigby <[EMAIL PROTECTED]> wrote:
> So get_immrbase can function without a device_type = "soc"
> property in the soc node.
>
> The "soc" node should really be named "immr"
> because it does not include the entire soc, however
> u-boot currently looks up this node
On Aug 5, 2008, at 3:49 PM, Scott Wood wrote:
Arnd Bergmann wrote:
On Tuesday 05 August 2008, John Rigby wrote:
This will allow the eventual removal of device_type = "soc"
properties in soc nodes.
Stupid question, but why not remove immrbase instead?
It seems that all users can be converted
Arnd Bergmann wrote:
On Tuesday 05 August 2008, John Rigby wrote:
This will allow the eventual removal of device_type = "soc"
properties in soc nodes.
Stupid question, but why not remove immrbase instead?
It seems that all users can be converted to use a reg
property of some actual device ins
On Tuesday 05 August 2008, John Rigby wrote:
> This will allow the eventual removal of device_type = "soc"
> properties in soc nodes.
Stupid question, but why not remove immrbase instead?
It seems that all users can be converted to use a reg
property of some actual device instead of making assump
Now that get_immrbase knows about immr aliases.
Some chip docs call this ccsr for 8[56]xx platforms
but we stick with immr for consistency across 8xxx.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/ksi8560.dts |3 ++-
arch/powerpc/boot/dts/mpc8536ds.dts
Now that get_immrbase knows about immr aliases.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc8313erdb.dts|3 ++-
arch/powerpc/boot/dts/mpc8315erdb.dts|3 ++-
arch/powerpc/boot/dts/mpc832x_mds.dts|3 ++-
arch/powerpc/boot/dts/mpc832x_rdb.dts
This will allow the eventual removal of device_type = "soc"
properties in soc nodes.
Signed-off-by: John Rigby <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 25 +++--
1 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/ar
So get_immrbase can function without a device_type = "soc"
property in the soc node.
The "soc" node should really be named "immr"
because it does not include the entire soc, however
u-boot currently looks up this node by name for
a clock fixup so leave it "soc" for now. We will change
it later af
Chris Friesen wrote:
Kevin Diggs wrote:
Hi,
I have the following near the top of my cpufreq driver target
routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here!
Kevin Diggs wrote:
Hi,
I have the following near the top of my cpufreq driver target routine:
while(test_and_set_bit(cf750gxmCfgChangeBit,&cf750gxvStateBits)) {
/*
* Someone mucking with our cfg? (I hope it is ok to call
* schedule() here! - truth is I have no ide
On Tue, 2008-08-05 at 17:28 +0100, Mel Gorman wrote:
> Ok sure, you could do direct inserts for MAP_PRIVATE as conceptually it
> suits this patch. However, I don't see what you gain. By reusing hugetlbfs,
> we get things like proper reservations which we can do for MAP_PRIVATE these
> days. Again,
So when we receive a spurious irq, EOI it, and then mask it.
What happens when a new IRQ arrives on the interrupt controller
between these EOI and mask calls? Should you instead first mask
it, and only then EOI it? Or doesn't that work on XICS?
Segher
___
On (05/08/08 09:12), Dave Hansen didst pronounce:
> On Tue, 2008-08-05 at 12:11 +0100, Mel Gorman wrote:
> > See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
> > To get that right between children, you end up something very fs-like
> > when the child needs to fault in a page
On Aug 5, 2008, at 11:09 AM, Sean MacLennan wrote:
Almost all of the includes in include/asm-powerpc where moved to
arch/powerpc/include/asm. This is breaking almost all of my user mode
code... so I assume I am doing something very wrong.
Here is a simple program that flushes stdout for no app
On Tue, 2008-08-05 at 12:11 +0100, Mel Gorman wrote:
> See, that's great until you start dealing with MAP_SHARED|MAP_ANONYMOUS.
> To get that right between children, you end up something very fs-like
> when the child needs to fault in a page that is already populated by the
> parent. I strongly sus
Almost all of the includes in include/asm-powerpc where moved to
arch/powerpc/include/asm. This is breaking almost all of my user mode
code... so I assume I am doing something very wrong.
Here is a simple program that flushes stdout for no apparent reason ;)
#include
#include
int main(int argc
Recent of_platform changes made of_bus_type_init() overwrite the bus type's
.dev_attrs list, so move ibmebus' "name" attribute (which is needed by eHCA
userspace support) into generic OF device code. Tested on POWER.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ibmebu
In the xics code, if we receive an irq during boot that hasn't been setup
yet - ie. we have no reverse mapping for it - we mask the irq so we don't
hear from it again.
Later on if someone request_irq()'s that irq, we'll unmask it but it will
still never fire. This is because we never EOI'ed the ir
I'm trying to get the ppc6xx_defconfig booting on any 8641 (74xx/e600)
system. If I remove the 'simple-bus' compatible from the soc node in
the .dts it works. Otherwise it hangs at but and looks to be crashed
in the serial driver due to accessing memory at 0.
I've tried the same .dts (w/'
On Tue, 05 Aug 2008 13:39:49 +0200 Johannes Berg <[EMAIL PROTECTED]> wrote:
> LD vmlinux.o
> mm/built-in.o: In function `.arch_get_unmapped_area_topdown':
> (.text+0x1d084): multiple definition of `.arch_get_unmapped_area_topdown'
> arch/powerpc/mm/built-in.o:(.text+0x7240): first defined h
On Tue, 2008-08-05 at 21:43 +1200, Paul Collins wrote:
> Michael Ellerman <[EMAIL PROTECTED]> writes:
>
> > I see you have FTRACE enabled. That's new and could potentially bugger
> > things up without the compiler knowing, so can you turn that off.
>
> With FTRACE disabled, doing cross-builds fro
LD vmlinux.o
mm/built-in.o: In function `.arch_get_unmapped_area_topdown':
(.text+0x1d084): multiple definition of `.arch_get_unmapped_area_topdown'
arch/powerpc/mm/built-in.o:(.text+0x7240): first defined here
mm/built-in.o: In function `arch_get_unmapped_area_topdown':
(.opd+0x2730): multi
> You could do that by adding:
>
> if (!(pteflags & (_PAGE_USER | _PAGE_RW)))
> rflags |= (1 << 1) | (1 << 63);
>
> Dbl check that the resulting mapping isn't accessible to user space though.
Make these 1UL << x, and a proper patch would have to also test
that the CPU suppor
On (04/08/08 14:10), Dave Hansen didst pronounce:
> On Thu, 2008-07-31 at 11:31 +0100, Mel Gorman wrote:
> > We are a lot more reliable than we were although exact quantification is
> > difficult because it's workload dependent. For a long time, I've been able
> > to test bits and pieces with hugep
On Mon, 04 Aug 2008 09:31:36 -0700 Daniel Walker <[EMAIL PROTECTED]> wrote:
> On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
>
> > --- a/arch/powerpc/include/asm/irq.h
> > +++ b/arch/powerpc/include/asm/irq.h
> > @@ -119,6 +119,7 @@ struct irq_host {
> > } linear;
> >
On Tue, 05 Aug 2008 11:05:03 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> > - Remove the populating of the tree from the revmap function as
> >you already do
> > - Move it to irq_create_mapping() for the normal case
> > - For pre-existing interrupt, have the generic code th
> arch/powerpc/platfroms/ps3/htab.c:ps3_hpte_updatepp() uses `htab[slot].v'.
Ah, I missed that one. Indeed it -is- used.
Ok, that leaves us with 2 options:
- Change ps3_hpte_updatepp() to not read from the hash table via that
mapping (ie, do you have an LV1 call to read an HPTE ? Do you measur
Michael Ellerman <[EMAIL PROTECTED]> writes:
> I see you have FTRACE enabled. That's new and could potentially bugger
> things up without the compiler knowing, so can you turn that off.
With FTRACE disabled, doing cross-builds from the 2.6.26 amd64 client, a
setup that normally triggers the probl
On Tue, 5 Aug 2008, Benjamin Herrenschmidt wrote:
> > > Can you find out where that stupid value comes from ?
> >
> > I didn't have time to look at in detail, but it fails from the
> > ioremap call in ps3_map_htab (arch/powerpc/platfroms/ps3/htab.c):
> >
> > htab = (__force struct hash_pte *)ior
Hi Benjamin,
On Tue, 05 Aug 2008 11:03:46 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
> On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
> > The radix tree used for fast irq reverse mapping by the XICS is initialized
> > late in the boot process, after the first interrupt
On Tue, 2008-08-05 at 17:28 +1000, Stephen Rothwell wrote:
> Hi Ben,
>
> Just a trivial note ..
>
> On Tue, 05 Aug 2008 16:19:56 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> wrote:
> >
> > +++ linux-work/arch/powerpc/mm/hash_utils_64.c 2008-08-05
> > 16:09:47.0 +1000
> > @@ -
Hi Ben,
Just a trivial note ..
On Tue, 05 Aug 2008 16:19:56 +1000 Benjamin Herrenschmidt <[EMAIL PROTECTED]>
wrote:
>
> +++ linux-work/arch/powerpc/mm/hash_utils_64.c2008-08-05
> 16:09:47.0 +1000
> @@ -18,7 +18,7 @@
> * 2 of the License, or (at your option) any later version.
On Tue, 2008-08-05 at 16:47 +1200, Paul Collins wrote:
> It's about four years old. It was in storage for about six months and I
> got it repaired a few weeks ago (display cable and inverter). The sort
> of crazy crap I've been reporting certainly smacks of memory corruption.
> But on the other h
80 matches
Mail list logo
