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 driver ports
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
From: Jeff Garzik [EMAIL PROTECTED]
Date: Thu, 09 Aug 2007 02:31:11 -0400
Either way, I'll want you to push to Linus before I do, when the next
merge window opens.
No problem.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
On Thu, 2007-08-09 at 01:35 -0500, Kumar Gala wrote:
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
Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---
This patch should apply cleanly on top of Stefan's recent patchset. Please
review and apply for 2.6.23. Thanks.
drivers/infiniband/hw/ehca/ehca_hca.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git
It might be worth checking that there isn't a particular reason for
these. Just because posting writes are forbidden doesn't mean a
particular bridge won't screw it up...
Well, I had already checked with Ben, who wrote the code, and my
understanding is that the reads are intended to work
On Thu, Aug 09, 2007 at 12:28:20AM -0500, Kumar Gala wrote:
Did you actually see this happen?
Yes.
When?
During some bluegene debug.
We don't have critical wired to anything, I don't expect watchdog to
cause another fault.. so just wondering.
We being who? I'm slightly confused
On Wed, 08 Aug 2007 13:45:10 -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.
Here is the output:
= tftp 40
On Thu, 2007-08-09 at 07:04 -0500, Josh Boyer wrote:
We don't have critical wired to anything, I don't expect watchdog
to
cause another fault.. so just wondering.
We being who? I'm slightly confused here.
I think Kumar doesn't know that we are talking about the BG kernel which
has
On Thu, 09 Aug 2007 23:05:36 +1000
Benjamin Herrenschmidt [EMAIL PROTECTED] wrote:
On Thu, 2007-08-09 at 07:04 -0500, Josh Boyer wrote:
We don't have critical wired to anything, I don't expect watchdog
to
cause another fault.. so just wondering.
We being who? I'm slightly
On Thu, 09 Aug 2007 14:58:55 +0400
Valentine Barshak [EMAIL PROTECTED] wrote:
David Gibson wrote:
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
Nope definitely using a uImage. I'll try a fresh source and try again ..
I did base it on kernel.org git tree so I'll try instead with 2.6.23-rc2
and see what happens.
n Thu, 2007-08-09 at 16:56 +0400, Vitaly Bordug wrote:
On Wed, 08 Aug 2007 13:45:10 -0500
Jerone Young wrote:
Using the
Alexandros Kostopoulos wrote:
Hi Scott,
please allow me to insist a little bit more on this.
No problem. :-)
1. As far as the device tree is concerned, it is defined that the first 3
numbers in every line of the ranges property (for our case, with #address-
cells=3) is the PCI address
So did a rebase on kernel.org 2.6.23-rc2 patch (as opposed the latest
git). I am using Uboot version 1.2.0-gc0c292b2. This is the version
that came with the board. It still appears to hang during early boot on
my Sequoia.
Trying the cuImage.sequoia.bin.gz just result in Uboot giving Bad Magic
It means the bus on which legacy I/O ports can be found. It's a fairly
broken concept; each host bridge should really be treated as a
completely separate entity, and if something like a VGA card has legacy
I/O ports that need to be used, they should be looked for on the same
PCI bus as the
Josh Boyer wrote:
On Thu, 09 Aug 2007 14:58:55 +0400
Valentine Barshak [EMAIL PROTECTED] wrote:
David Gibson wrote:
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
That's hardly the only reason. But yeah, that's one way to
implement the workaround, but _we_ (the Linux community) cannot
do it like that (easily) for all users.
But you're the guy who told us our firmware sucks and we should fix our
firmware
Yes, and? You _should_ fix your firmware, it
Jerone Young wrote:
So did a rebase on kernel.org 2.6.23-rc2 patch (as opposed the latest
git). I am using Uboot version 1.2.0-gc0c292b2. This is the version
that came with the board. It still appears to hang during early boot on
my Sequoia.
Trying the cuImage.sequoia.bin.gz just result in
Segher Boessenkool wrote:
Would you guys rather we shipped a boot script that ran the OS, fixed
all these issues in-place in-firmware, so Linux did not have to have
these
workarounds,
Sure, if you can do that, that would be great.
Right, so don't accept that keyboard fix, and we will
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/rtas_pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/rtas_pci.c b/arch/powerpc/kernel/rtas_pci.c
index a5de621..21f14e5 100644
--- a/arch/powerpc/kernel/rtas_pci.c
+++
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/celleb/pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/pci.c
b/arch/powerpc/platforms/celleb/pci.c
index e9ac19c..de8038b 100644
---
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/celleb/scc_epci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/celleb/scc_epci.c
b/arch/powerpc/platforms/celleb/scc_epci.c
index c4b0110..7506acc 100644
---
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/maple/pci.c | 12 ++--
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/platforms/maple/pci.c
b/arch/powerpc/platforms/maple/pci.c
index 2542403..6247f94 100644
---
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/pasemi/pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/pasemi/pci.c
b/arch/powerpc/platforms/pasemi/pci.c
index ab1f5f6..882b571 100644
---
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/powermac/pci.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/powerpc/platforms/powermac/pci.c
b/arch/powerpc/platforms/powermac/pci.c
index 92586db..69d67ff 100644
---
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/kernel/pci_32.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index 04a3109..0e2bee4 100644
--- a/arch/powerpc/kernel/pci_32.c
+++
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/52xx/efika.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/52xx/efika.c
b/arch/powerpc/platforms/52xx/efika.c
index 4be6e7a..4263158 100644
---
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/platforms/chrp/pci.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/platforms/chrp/pci.c
b/arch/powerpc/platforms/chrp/pci.c
index 28d1647..0c6dba9 100644
---
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
---
arch/powerpc/sysdev/tsi108_pci.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/sysdev/tsi108_pci.c b/arch/powerpc/sysdev/tsi108_pci.c
index 90db8a7..cf0bfbd 100644
--- a/arch/powerpc/sysdev/tsi108_pci.c
On Thu, Aug 09, 2007 at 02:18:40PM -0500, Nathan Lynch wrote:
Signed-off-by: Nathan Lynch [EMAIL PROTECTED]
Acked-by: Olof Johansson [EMAIL PROTECTED]
Thanks!
-Olof
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
strncpy() won't put a terminating zero on there, is everything
that uses the resulting string okay with that? Also, if the
name gets cut short, it might match some _other_ expected name.
On Wed, 1 Aug 2007, Scott Wood wrote:
You could use strlcpy() instead, which always leaves a zero
On Wed, Aug 08, 2007 at 08:04:32PM -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 Lynch
I haven't heard or thought of anything better either. Using
ranges
is conceptually wrong, even ignoring the technical problems that
come
with it.
Why is ranges conceptually wrong?
The flash partitions aren't separate devices sitting on a
flash bus, they are sub-devices of their
For the JEDEC chips, we need a vendor-id and device-id
property at least (or similar names -- whatever is general
practice for this); both are a single byte, encoded as with
encode-int.
Ok... should those really be separate properties, or should that go in
compatible, i.e. something like:
Hrm... Freescale is using these 'fsl,device-id' properties, I'm
guessing they're basically the same thing as the 'cell-index' used in
the EMAC binding.
We should co-ordinate better on this, if it's to become a
convention...
That means we shouldn't coordinate on this, right?
Segher
- cosmetic cleanups (@01 - @1);
That's a correctness fix, not just cosmetics.
- other non-mandatory (device-id, device_type, compatible, ...)
properties removed from mmc node, today board file is using
of_find_node_by_name(), instead of of_find_compatible_node();
That's the
On Thu, 9 Aug 2007, Segher Boessenkool wrote:
strncpy() won't put a terminating zero on there, is everything
that uses the resulting string okay with that? Also, if the
name gets cut short, it might match some _other_ expected name.
On Wed, 1 Aug 2007, Scott Wood wrote:
You
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]
Respin of earlier patch, with the CONFIG_PSERIES junk removed from the
header file.
arch/powerpc/kernel/nvram_64.c
We don't need to look up the rtas event token once per
cpu per second. This avoids some misc device-tree lookups
and string ops and so provides some minor performance
improvement.
Signed-off-by: Linas Vepstas [EMAIL PROTECTED]
Revised commit-log message.
Segher Boessenkool wrote:
It might be worth checking that there isn't a particular reason for
these. Just because posting writes are forbidden doesn't mean a
particular bridge won't screw it up...
Well, I had already checked with Ben, who wrote the code, and my
understanding is that the
The powermac 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
It seems that some versions of firmware will report a device
node status as the string okay. As we are not expecting this
string, the device node will be ignored by the EEH subsystem.
Which means EEH will not be enabled.
When EEH is not enabled, PCI errors will be converted into
Machine Check
Geoff Levand wrote:
Arnd Bergmann wrote:
On Saturday 04 August 2007, Geoff Levand wrote:
From: Andre Detsch [EMAIL PROTECTED]
This patch moves affinity initialization code from spu_base.c to a
new spu_management_of_ops function (init_affinity), which is empty
in the case of PS3. This
On Mon, Aug 06, 2007 at 08:48:13AM -0500, Josh Boyer wrote:
On Fri, 27 Jul 2007 11:33:31 +1000
David Gibson [EMAIL PROTECTED] wrote:
On Thu, Jul 26, 2007 at 10:21:33AM -0500, Jon Loeliger wrote:
So, like, the other day David Gibson mumbled:
Only thing I'm not really happy with
On Fri, 10 Aug 2007 11:30:01 +1000
David Gibson [EMAIL PROTECTED] wrote:
Except didn't you say you were going to work with Stephen to get DTC
into the kernel source itself? Keeping things similar to Kbuild might
help in that effort.
Actually, after discussions with Stephen and Paulus,
On Thu, Aug 09, 2007 at 09:53:41PM +0200, Segher Boessenkool wrote:
I haven't heard or thought of anything better either. Using
ranges
is conceptually wrong, even ignoring the technical problems that
come
with it.
Why is ranges conceptually wrong?
The flash partitions aren't
On Thu, Aug 09, 2007 at 10:15:44PM +0200, Segher Boessenkool wrote:
Hrm... Freescale is using these 'fsl,device-id' properties, I'm
guessing they're basically the same thing as the 'cell-index' used in
the EMAC binding.
We should co-ordinate better on this, if it's to become a
Hey guys,
Well, I tagged and released an official DTC v1.0.0 Release
and pushed it out to jdl.com just now. You can grab the
git repo directly:
git://www.jdl.com/software/dtc.git
or download a tarball here:
http://www.jdl.com/software/dtc-1.0.0.tgz
As usual, please let me know of any
On Thu, Aug 09, 2007 at 10:00:47PM +0200, Segher Boessenkool wrote:
For the JEDEC chips, we need a vendor-id and device-id
property at least (or similar names -- whatever is general
practice for this); both are a single byte, encoded as with
encode-int.
Ok... should those really be
On Thu, Aug 09, 2007 at 08:01:33PM -0500, Jon Loeliger wrote:
Hey guys,
Well, I tagged and released an official DTC v1.0.0 Release
and pushed it out to jdl.com just now. You can grab the
git repo directly:
git://www.jdl.com/software/dtc.git
or download a tarball here:
David Gibson wrote:
Except didn't you say you were going to work with Stephen to get DTC
into the kernel source itself? Keeping things similar to Kbuild might
help in that effort.
Actually, after discussions with Stephen and Paulus, we decided not to
take this route.
Could you please let
This adds code to handle alignment traps generated by the following
new floating-point load/store instructions, by emulating the
instruction in the kernel (as is done for other instructions that
generate alignment traps):
lfiwax load floating-point as integer word algebraic indexed
stfiwx store
52 matches
Mail list logo
