Hi Geoff,
On Tue, 07 Aug 2007 20:31:19 -0700 [EMAIL PROTECTED] wrote:
>
> This small set of PS3 bugfix patches for 2.6.23.
>
> [patch 1/3] PS3: Fix storage probe logic
> [patch 2/3] PS3: Remove incomplete message
> [patch 3/3] PS3: Update ps3_defconfig
>
> Patch 1 fixes a cold startup timi
> * c++ style comments
Ouch... I haven't removed them all ? I promise I didn't -add- any :-)
> * in emac_probe():
> + /* Wait for dependent devices */
> + err = -ENODEV;
> + err = emac_wait_deps(dev);
> The initialisation to -ENODEV is pointless right?
On Wed, 2007-08-08 at 15:09 +1000, David Gibson wrote:
>
> Eh, all the c++ comments are FIXMEs anyway. I'm inclined to leave
> them.
Ahah... maybe I -did- add some of those then :-) I do use C++ comments
for FIXME's on purpose, because they are ugly, it improves the changes
that I actually get t
Hi Geoff,
On Wed, 8 Aug 2007 17:17:38 +1000 Stephen Rothwell <[EMAIL PROTECTED]>
wrote:
>
> LD .tmp_vmlinux1
> arch/powerpc/platforms/built-in.o: In function `of_has_vicinity':
> /home/sfr/kernels/linus/arch/powerpc/platforms/cell/spu_base.c:681:
> undefined reference to `.spu_devnode'
Ben
On Tue, 7 Aug 2007 [EMAIL PROTECTED] wrote:
> Remove the Kconfig message that indicates the PS3 platform support is
> incomplete.
>
> Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
> ---
> arch/powerpc/platforms/ps3/Kconfig | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
On Tue, 31 Jul 2007, Stephen Rothwell wrote:
> WARNING: vmlinux.o(.text+0x8174): Section mismatch: reference to
> .init.text:.prom_init (between '.__boot_from_prom' and '.__after_prom_start')
> WARNING: vmlinux.o(.text+0x8498): Section mismatch: reference to
> .init.text:.early_setup (between '.s
On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <[EMAIL PROTECTED]>
wrote:
> Alexandros Kostopoulos wrote:
>> Except from some macros arch/powerpc/include/asm/io.h / mpc8260_pci9.h,
>> I can seem to find anywhere the code regarding PCI Erratum 9. The
>> defined macros(in io.h) for read/writ
On Wed, 2007-08-08 at 17:47 +1000, Stephen Rothwell wrote:
> Hi Geoff,
>
> On Wed, 8 Aug 2007 17:17:38 +1000 Stephen Rothwell <[EMAIL PROTECTED]>
> wrote:
> >
> > LD .tmp_vmlinux1
> > arch/powerpc/platforms/built-in.o: In function `of_has_vicinity':
> > /home/sfr/kernels/linus/arch/powerpc/
On Wed, 08 Aug 2007 14:42:34 +0300, Alexandros Kostopoulos
<[EMAIL PROTECTED]> wrote:
> On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood <[EMAIL PROTECTED]>
> wrote:
>
>> Alexandros Kostopoulos wrote:
>>> Except from some macros arch/powerpc/include/asm/io.h /
>>> mpc8260_pci9.h, I can seem t
Hello Roland!
Haven't got any ack for this updated patch yet. Anyway, since it contains
another bug as shown below, please ignore this patch. We'll send a patch
set that includes the proper version of this patch later.
> @@ -109,7 +109,7 @@ static int ehca_mmap_fw(struct vm_area_struct *vma,
> s
Hi all,
I've noticed the following: In function pci_process_bridge_OF_ranges, when
parsing the ranges for MEM and I/O space, the res->start for mem is
correctly set to ranges[na+2], which is the cpu address in the ranges
property. However, in I/O related code, res->start is set to ranges[2],
On Tue, 7 Aug 2007 14:20:50 +1000
David Gibson <[EMAIL PROTECTED]> wrote:
> The 440 family of processors don't have a tlbie instruction. So, we
> implement TLB invalidates by explicitly searching the TLB with tlbsx.,
> then clobbering the relevant entry, if any. Unfortunately the PID for
> the s
On Aug 6, 2007, at 11:20 PM, David Gibson wrote:
> The 440 family of processors don't have a tlbie instruction. So, we
> implement TLB invalidates by explicitly searching the TLB with tlbsx.,
> then clobbering the relevant entry, if any. Unfortunately the PID for
> the search needs to be stored
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 08, 2007 11:21 AM
> To: [EMAIL PROTECTED]
> Cc: [EMAIL PROTECTED]; linuxppc-dev@ozlabs.org; Todd Inglett;
> Volkmar Uhlig
> Subject: Re: Fix small race in 44x tlbie function
>
>
> On Aug 6
On Wed, 8 Aug 2007 10:20:45 -0500
Kumar Gala <[EMAIL PROTECTED]> wrote:
>
> On Aug 6, 2007, at 11:20 PM, David Gibson wrote:
>
> > The 440 family of processors don't have a tlbie instruction. So, we
> > implement TLB invalidates by explicitly searching the TLB with tlbsx.,
> > then clobbering t
> Haven't got any ack for this updated patch yet. Anyway, since it contains
> another bug as shown below, please ignore this patch. We'll send a patch
> set that includes the proper version of this patch later.
Yes, sorry, I'm a bit behind applying patches.
Anyway, OK I'll wait for a fixed pa
Alexandros Kostopoulos wrote:
>> Well, the error message is:
>> PCI::00:16.0: Resource 0: -0fff (f=200)
>> PCI: Cannot allocate resource region 0 of device :00:16.0
>> PCI: parent is c03c4058: 8000-bfff (f=200)
[snip]
> Oops, I think I fo
Well, I've played around with the sections a bit more, and just can't
seem to get it to work. As soon as I apply the following, the kernel
refuses to boot. (And if I remove the changes to _GLOBAL, then it
refuses to boot if I enable CONFIG_KPROBES.)
Index: linux/include/asm-ppc/processor.h
Alexandros Kostopoulos wrote:
> On Tue, 07 Aug 2007 18:20:12 +0300, Scott Wood
> <[EMAIL PROTECTED]> wrote:
>> I don't think the workaround exists yet in arch/powerpc, despite the
>> config option.
>>
> Is there a plan to be implemented on arch/powerpc, or devices with the
> erratum will have
Remove the Kconfig message that indicates the PS3 platform support is
incomplete.
Signed-off-by: Geoff Levand <[EMAIL PROTECTED]>
---
v2 changes:
o Fix typo pointed out by Geert
arch/powerpc/platforms/ps3/Kconfig | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
--- a/arch/po
Hi all,
This is v3. The only objection I can imagine is about "fsl,device-id".
Though in the v2 nobody complained, thus it's stayed intact.
If you want to, complain now. I'll give up and will remove it. ;-)
Changelog:
v2 -> v3
o Device tree:
- completely removed mmc node;
- removed pio-hand
mmc_spi already tested to work. When it will hit mainline
the only change that will be needed is replacing "spidev"
by "mmc_spi".
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc832x_rdb.dts |4 ++-
arch/powerpc/platforms/83xx/mpc832x_rdb.c | 52 +
Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
---
arch/powerpc/sysdev/fsl_soc.c | 88 +
arch/powerpc/sysdev/fsl_soc.h | 12 ++
2 files changed, 100 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/fsl_soc.c b/arch/powerpc/sysdev/f
Subject: PS3: Fix storage probe logic
From: Geert Uytterhoeven <[EMAIL PROTECTED]>
Fix the PS3 storage probe logic to properly find device regions on cold
startup.
o Change the storage probe event mask from notify_device_ready
to notify_region_update.
o Improve the storage probe error handl
Using the Sequoia (AMCC 440EPx) patches recently submitted to the list I
am unable to boot to fully boot a uImage built with these patches under
Uboot. It appears to hang in very early boot.
Here is the output:
=> tftp 40 sequoia/uImage
ENET
Hello all. In an effort to understand how the page tables are laid out
across various architectures I put together some diagrams. I have
posted them on the linux-mm wiki: http://linux-mm.org/PageTableStructure
and I hope they will be useful to others.
Just to make sure I am not spreading misin
Here is a patch set against Roland's git, branch for-2.6.23 for ehca.
It enables userspace support for small QP feature and make some fixes for it.
Also there is add the mapping of 4k firmware context to user space.
They are in details:
[1/7] add support for userspace small queues and make some f
Signed-off-by: Stefan Roscher <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_qp.c |7 +++
drivers/infiniband/hw/ehca/ipz_pt_fn.c |3 ++-
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.
Signed-off-by: Stefan Roscher <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_qp.c | 10 ++
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.c
index cfa83fa..13b61c3 100644
--- a/drivers/infi
Signed-off-by: Stefan Roscher <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/hcp_if.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/hcp_if.c
b/drivers/infiniband/hw/ehca/hcp_if.c
index 24f4541..8534061 100644
--- a/drivers/infiniband/hw
Signed-off-by: Stefan Roscher <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_cq.c |7 ++-
drivers/infiniband/hw/ehca/ehca_qp.c |6 ++
drivers/infiniband/hw/ehca/ehca_uverbs.c | 22 +++---
3 files changed, 23 insertions(+), 12 deletions(-)
diff --
From: Hoang-Nam Nguyen <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 19:33:23 +0200
This patch utilizes remap_4k_pfn() as introduced by Paul M.,
for details see http://patchwork.ozlabs.org/linuxppc/patch?id=10281,
to map ehca cq, qp firmware context (4k) to user space if kernel page
size is 64k. For r
From: Joachim Fenkes <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 19:51:30 +0200
Signed-off-by: Stefan Roscher <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_irq.c | 48 +---
1 files changed, 31 insertions(+), 17 deletions(-)
diff --git a/drivers/infiniband/hw
Signed-off-by: Stefan Roscher <[EMAIL PROTECTED]>
---
drivers/infiniband/hw/ehca/ehca_qp.c | 14 +-
1 files changed, 5 insertions(+), 9 deletions(-)
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c
b/drivers/infiniband/hw/ehca/ehca_qp.c
index d8c1c22..6efda3d 100644
--- a/drivers/
Alexandros Kostopoulos wrote:
> I've noticed the following: In function pci_process_bridge_OF_ranges,
> when parsing the ranges for MEM and I/O space, the res->start for mem
> is correctly set to ranges[na+2], which is the cpu address in the
> ranges property. However, in I/O related code, re
Scott Wood <[EMAIL PROTECTED]> said:
> Alexandros Kostopoulos wrote:
> > I've noticed the following: In function pci_process_bridge_OF_ranges,
> > when parsing the ranges for MEM and I/O space, the res->start for mem
> > is correctly set to ranges[na+2], which is the cpu address in the
> > ra
Alexandros Kostopoulos wrote:
> I was referring to the allocation of primary bus' IO space based on the
> device tree. I understand that IO-space resources are relative to the start
> of the primary bus' IO space. But I think the primary bus IO space allocation
> itself is broken. Let me explain
Paul,
Please apply te following for 2.6.24
The following sequence of patches cleanup, simplify and shorten
the pseries code having to do with error logging. Several
global variables shared across directories are removed, and
the rtasd initialization sequence is rearranged and simplified,
making
We don't need to look up the rtas event token once per
cpu per second. This avoids some misc string ops and
rtas calls and provides some minor performance improvement.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/platforms/pseries/rtasd.c | 15 +--
1 file c
The rtas_token() call does the same thing as this hand-rolled code.
This makes the code easier to read.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/platforms/pseries/rtasd.c | 13 ++---
1 file changed, 2 insertions(+), 11 deletions(-)
Index: linux-2.6.22-git2/a
Simplify rtasd initialization code; this also fixes a buglet,
where the /proc entries weren't being cleaned up in case of
failure.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/platforms/pseries/rtasd.c | 53 +++--
1 file changed, 19 insertio
Forward declarations serve no purpose in this file.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/kernel/nvram_64.c |5 -
1 file changed, 5 deletions(-)
Index: linux-2.6.22-git2/arch/powerpc/kernel/nvram_64.c
===
Get rid of the jumbled usage of the no_logging flag. Its use
spans several directories, and is incorrectly/misleadingly
documented. Instead, two changes:
1) nvram will accept error log as soon as its ready.
2) logging to nvram stops on the first fatal error reported.
Signed-off-by: Linas Vepstas
Eliminate the use of error_log_cnt as a global var shared across
differnt directories. Pass it as a subroutine arg instead.
Signed-off-by: Linas Vepstas <[EMAIL PROTECTED]>
arch/powerpc/kernel/nvram_64.c | 10 +-
arch/powerpc/platforms/pseries/rtasd.c |7 ---
incl
On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
>
> This patch fixes the problem in both arch/ppc and arch/powerpc by
> inhibiting interrupts (even critical and debug interrupts) across the
> relevant instructions.
How could a critical or debug interrupt modify the contents of MMUCR?
--
On Wed, 8 Aug 2007 20:43:25 + (UTC)
Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> >
> > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > inhibiting interrupts (even critical and debug interrupts) across the
> > rel
Hi,
This patch is needed in order to compile kernel modules that uses some
of the DCR functions. For example, compiling powerpc emac driver as
module it is needed.
Arnd, Dennis Spathis pinged me about this today and I thought it was a
closed issue but still open. If you find it okay please upstre
Linas Vepstas wrote:
> --- linux-2.6.22-git2.orig/include/asm-powerpc/nvram.h2007-07-08
> 18:32:17.0 -0500
> +++ linux-2.6.22-git2/include/asm-powerpc/nvram.h 2007-08-08
> 13:34:27.0 -0500
> @@ -62,14 +62,19 @@ struct nvram_partition {
> unsigned int index;
> };
Linas Vepstas wrote:
>
> We don't need to look up the rtas event token once per
> cpu per second. This avoids some misc string ops and
> rtas calls and provides some minor performance improvement.
It does not avoid any calls to RTAS. (rtas_token merely looks up
properties under the /rtas node.
On Wednesday 08 August 2007, Murali Iyer wrote:
> This patch is needed in order to compile kernel modules that uses some
> of the DCR functions. For example, compiling powerpc emac driver as
> module it is needed.
Ok, thanks!
> Arnd, Dennis Spathis pinged me about this today and I thought it was
On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> On Wed, 8 Aug 2007 20:43:25 + (UTC)
> Hollis Blanchard <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > >
> > > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > > inhibiting
On Wed, Aug 08, 2007 at 04:57:39PM -0500, Nathan Lynch wrote:
> Linas Vepstas wrote:
> >
> > We don't need to look up the rtas event token once per
> > cpu per second. This avoids some misc string ops and
> > rtas calls and provides some minor performance improvement.
>
> It does not avoid any
> No, because as I said, res->start is relative to the start of IO-space.
> The in/out functions add isa_io_base to the address.
>
Hi Scott,
please allow me to insist a little bit more on this.
1. As far as the device tree is concerned, it is defined that the first 3
numbers in every line
On Wed, Aug 08, 2007 at 04:57:14PM -0500, Nathan Lynch wrote:
> Linas Vepstas wrote:
> > +
> > +#ifdef CONFIG_PPC_PSERIES
> > +extern int pSeries_nvram_init(void);
> > +extern int nvram_write_error_log(char * buff, int length,
> > +unsigned int err_type, unsigned
>From 32ad910d7d88e754102f3101b8869c4ca68efb53 Mon Sep 17 00:00:00 2001
From: Randy Vinson <[EMAIL PROTECTED]>
Date: Wed, 8 Aug 2007 15:45:58 -0700
Subject: [PATCH] 85xxCDS: Fix building without PCI.
Signed-off-by: Randy Vinson <[EMAIL PROTECTED]>
---
arch/powerpc/platforms/85xx/mpc85xx_cds.c |
On Wed, 2007-08-08 at 17:21 +0300, Alexandros Kostopoulos wrote:
> I've noticed the following: In function pci_process_bridge_OF_ranges, when
> parsing the ranges for MEM and I/O space, the res->start for mem is
> correctly set to ranges[na+2], which is the cpu address in the ranges
> propert
On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> On Wed, 8 Aug 2007 20:43:25 + (UTC)
> Hollis Blanchard <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > >
> > > This patch fixes the problem in both arch/ppc and arch/powerpc by
> > > inhibiting
On Wed, Aug 08, 2007 at 05:11:09PM -0500, Hollis Blanchard wrote:
> On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> > On Wed, 8 Aug 2007 20:43:25 + (UTC)
> > Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > > >
> > > > Th
On Wed, 2007-08-08 at 17:11 -0500, Hollis Blanchard wrote:
> On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> > On Wed, 8 Aug 2007 20:43:25 + (UTC)
> > Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > > >
> > > > This patc
On Thu, Aug 09, 2007 at 09:01:29AM +1000, Benjamin Herrenschmidt wrote:
> On Wed, 2007-08-08 at 16:29 -0500, Josh Boyer wrote:
> > On Wed, 8 Aug 2007 20:43:25 + (UTC)
> > Hollis Blanchard <[EMAIL PROTECTED]> wrote:
> >
> > > On Tue, 07 Aug 2007 14:20:50 +1000, David Gibson wrote:
> > > >
> >
The maple pci configuration space write methods read the written
location immediately after the write is performed, presumably in order
to flush the write. However, configuration space writes are not
allowed to be posted, making these reads gratuitous. Furthermore,
this behavior potentially cause
On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote:
> The maple pci configuration space write methods read the written
> location immediately after the write is performed, presumably in order
> to flush the write. However, configuration space writes are not
> allowed to be posted, making these
Linas Vepstas wrote:
> On Wed, Aug 08, 2007 at 04:57:14PM -0500, Nathan Lynch wrote:
> > Linas Vepstas wrote:
> > > +
> > > +#ifdef CONFIG_PPC_PSERIES
> > > +extern int pSeries_nvram_init(void);
> > > +extern int nvram_write_error_log(char * buff, int length,
> > > +
Benjamin Herrenschmidt wrote:
> On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote:
> >
> > Remove the gratuitous reads from u3_agp_write_config,
> > u3_ht_write_config, and u4_pcie_write_config.
> >
> > Signed-off-by: Nathan Lynch <[EMAIL PROTECTED]>
>
> Acked-by: Benjamin Herrenschmidt <[EM
On Wed, 2007-08-08 at 20:04 -0500, Nathan Lynch wrote:
> Benjamin Herrenschmidt wrote:
> > On Wed, 2007-08-08 at 19:50 -0500, Nathan Lynch wrote:
> > >
> > > Remove the gratuitous reads from u3_agp_write_config,
> > > u3_ht_write_config, and u4_pcie_write_config.
> > >
> > > Signed-off-by: Nathan
On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
> The maple pci configuration space write methods read the written
> location immediately after the write is performed, presumably in order
> to flush the write. However, configuration space writes are not
> allowed to be posted, making
On Wed, Aug 08, 2007 at 09:09:21PM +0400, Anton Vorontsov wrote:
> mmc_spi already tested to work. When it will hit mainline
> the only change that will be needed is replacing "spidev"
> by "mmc_spi".
>
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> arch/powerpc/boot/dts/mpc832x_rdb
On Wed, Aug 08, 2007 at 01:45:10PM -0500, Jerone Young wrote:
> Using the Sequoia (AMCC 440EPx) patches recently submitted to the list I
> am unable to boot to fully boot a uImage built with these patches under
> Uboot. It appears to hang in very early boot.
I'm guessing this is an old version of
David Gibson wrote:
> On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
> > The maple pci configuration space write methods read the written
> > location immediately after the write is performed, presumably in order
> > to flush the write. However, configuration space writes are not
>
On Wed, Aug 08, 2007 at 11:16:32PM -0500, Nathan Lynch wrote:
> David Gibson wrote:
> > On Wed, Aug 08, 2007 at 07:50:44PM -0500, Nathan Lynch wrote:
> > > The maple pci configuration space write methods read the written
> > > location immediately after the write is performed, presumably in order
>
On Aug 8, 2007, at 11:00 AM, Josh Boyer wrote:
> On Wed, 8 Aug 2007 10:20:45 -0500
> Kumar Gala <[EMAIL PROTECTED]> wrote:
>
>>
>> On Aug 6, 2007, at 11:20 PM, David Gibson wrote:
>>
>>> The 440 family of processors don't have a tlbie instruction. So, we
>>> implement TLB invalidates by explicit
On Aug 8, 2007, at 12:09 PM, Anton Vorontsov wrote:
> Signed-off-by: Anton Vorontsov <[EMAIL PROTECTED]>
> ---
> arch/powerpc/sysdev/fsl_soc.c | 88 ++
> +++
> arch/powerpc/sysdev/fsl_soc.h | 12 ++
> 2 files changed, 100 insertions(+), 0 deletions(-)
On Aug 8, 2007, at 12:07 PM, Anton Vorontsov wrote:
> Hi all,
>
> This is v3. The only objection I can imagine is about "fsl,device-id".
> Though in the v2 nobody complained, thus it's stayed intact.
>
> If you want to, complain now. I'll give up and will remove it. ;-)
:), here's my complaint f
On Thu, Aug 09, 2007 at 12:28:20AM -0500, Kumar Gala wrote:
>
> On Aug 8, 2007, at 11:00 AM, Josh Boyer wrote:
>
> > On Wed, 8 Aug 2007 10:20:45 -0500
> > Kumar Gala <[EMAIL PROTECTED]> wrote:
> >
> >>
> >> On Aug 6, 2007, at 11:20 PM, David Gibson wrote:
> >>
> >>> The 440 family of processors d
From: Jan-Bernd Themann <[EMAIL PROTECTED]>
Date: Fri, 3 Aug 2007 14:41:14 +0200
> I think this patch could be the final version for now. It has been tested
> on two platforms (power and x86_64) and works very well.
I checked in the LRO patch and the two sample driver ports
to net-2.6.24, thanks!
David Miller wrote:
> From: Jan-Bernd Themann <[EMAIL PROTECTED]>
> Date: Fri, 3 Aug 2007 14:41:14 +0200
>
>> I think this patch could be the final version for now. It has been tested
>> on two platforms (power and x86_64) and works very well.
>
> I checked in the LRO patch and the two sample dri
Did you actually see this happen?
>>>
>>> Yes.
>>
>> When?
>>
>> We don't have critical wired to anything, I don't expect watchdog to
>> cause another fault.. so just wondering.
>
> On debug (trace) interrupts on blue gene.
Do you know why the debug code caused a fault?
- k
_
77 matches
Mail list logo
