On Aug 31, 2010, at 10:40 PM, Li Yang wrote:
On Wed, Sep 1, 2010 at 5:39 AM, Kumar Gala ga...@kernel.crashing.org wrote:
On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
Fixes the following compile problem on E500 platforms:
arch/powerpc/sysdev/fsl_rio.c: In function
On Aug 31, 2010, at 9:55 PM, Sean MacLennan wrote:
On Tue, 31 Aug 2010 13:46:05 -0400
Sean MacLennan smaclen...@pikatech.com wrote:
On Tue, 31 Aug 2010 11:17:17 -0500
Kumar Gala ga...@kernel.crashing.org wrote:
Can we add proper CONFIG_PPC_FPU into this file.
If nobody beats me to
On Wed, 1 Sep 2010 01:45:46 -0500
Kumar Gala ga...@kernel.crashing.org wrote:
For what defconfig setup do you get the errors above?
44x/ebony_defconfig
Then enable KPROBES (or XMON).
Then put an #ifdef CONFIG_PPC_FPU in ldstfp.S.
Cheers,
Sean
On 08/31/2010 05:31 AM, Alexander Graf wrote:
Howdy,
This is my local patch queue with stuff that has accumulated over the last
weeks on KVM for PPC with some last minute fixes, speedups and debugging help
that I needed for the KVM Forum ;-).
The highlights of this set are:
- Converted
Subject: Re: [PATCH v2 1/4] fsl_rio: fix compile errors
On Aug 31, 2010, at 10:40 PM, Li Yang wrote:
On Wed, Sep 1, 2010 at 5:39 AM, Kumar Gala ga...@kernel.crashing.org
wrote:
On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
Fixes the following compile problem on E500 platforms:
On Tue, Aug 31, 2010 at 10:55:25PM -0400, Sean MacLennan wrote:
I had to give up. Without the CONFIG_PPC_FPU it compiles fine for an
FPU less 44x. But with the CONFIG_PPC_FPU, I get the following errors:
Ah, those references would be from arch/powerpc/lib/sstep.c. Evidently
we need #ifdef
Hello,
we are seeing a strange behavior when trying to use the QE Ethernet interfaces.
ENET5 (UCC5 - RMII) interface on P1021MDS boards does not come up if there is
no physical link on the ENET1 (UCC1 - MII) Port.
It seems that interrupts from ENET5 are normally received but the link comes up
On Sep 1, 2010, at 3:02 AM, Paul Mackerras wrote:
On Tue, Aug 31, 2010 at 10:55:25PM -0400, Sean MacLennan wrote:
I had to give up. Without the CONFIG_PPC_FPU it compiles fine for an
FPU less 44x. But with the CONFIG_PPC_FPU, I get the following errors:
Ah, those references would be from
Matthew McClintock wrote:
+#ifndef CONFIG_SMP
stale_map[0] = alloc_bootmem(CTX_MAP_SIZE);
+#else
+ stale_map[boot_cpuid] = alloc_bootmem(CTX_MAP_SIZE);
So you're saying that even on a non-SMP kernel, boot_cpuid might not be zero?
___
On Sep 1, 2010, at 8:05 AM, Timur Tabi wrote:
Matthew McClintock wrote:
+#ifndef CONFIG_SMP
stale_map[0] = alloc_bootmem(CTX_MAP_SIZE);
+#else
+stale_map[boot_cpuid] = alloc_bootmem(CTX_MAP_SIZE);
So you're saying that even on a non-SMP kernel, boot_cpuid might not be zero?
On Wed, 2010-09-01 at 09:43 +0800, Liang Li wrote:
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel oops occur:
[...]
- ug_info-bdRingLenRx[queue] =
Hi Andy,
I've been looking at the phylib code, and specifically at the use of
the ERR_PTR() pattern. I'm personally not a big fan of ERR_PTR()
because the compiler cannot type check the result and it runs
completely counter to the pattern if (!ptr) than is common for
testing a pointer return
Grant Likely schrieb:
On Tue, Aug 31, 2010 at 10:16 AM, Vasiliy Kulikov sego...@gmail.com wrote:
On Tue, Aug 31, 2010 at 18:08 +0200, Julia Lawall wrote:
On Tue, 31 Aug 2010, walter harms wrote:
if (strncmp(model, PowerBook, strlen(PowerBook)) != 0
strncmp(model, iBook,
On 08/31/2010 10:54 PM, Michael Ellerman wrote:
On Tue, 2010-08-31 at 00:12 -0700, Darren Hart wrote:
..
When running with the function plugin I had to stop the trace
immediately before entering start_secondary after an online or my traces
would not include the pseries_mach_cpu_die function,
Hi,
I am facing a strange problem with a PCI express device. I have written a
simple PCI driver(pci_skel sample driver for LDD book) just to detect a PCI
device and read its vender and device id from its configuration space. When
I connect the device on a standard i386 based PC, it works fine, as
On Tue, Aug 31, 2010 at 09:07:56PM +0400, Anton Vorontsov wrote:
On Tue, Aug 31, 2010 at 10:44:14AM -0600, Grant Likely wrote:
On Tue, Aug 31, 2010 at 2:37 AM, Anton Vorontsov cbouatmai...@gmail.com
wrote:
On Tue, Aug 31, 2010 at 02:03:44AM -0600, Grant Likely wrote:
On Tue, Aug 24,
From: Grant Likely grant.lik...@secretlab.ca
Date: Wed, 1 Sep 2010 08:42:49 -0600
It seems to me that phylib is one of the cases where the users (the
network drivers) don't actually care about the specific error code
when calling phylib functions. The drivers only seem to care whether
or not
On Tue, Aug 31, 2010 at 05:43:51PM +0900, Akinobu Mita wrote:
clk_get() should return an ERR_PTR value on error, not NULL.
Signed-off-by: Akinobu Mita akinobu.m...@gmail.com
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: linuxppc-dev@lists.ozlabs.org
applied, thanks.
g.
---
The file arch/powerpc/platforms/cell/celleb_scc_uhc.c contains the
following function:
static inline int uhc_clkctrl_ready(u32 val)
{
const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBCEN;
return((val mask) == mask);
}
The variable mask is a bit or of two identical constants. Later
On Wed, 1 Sep 2010, Joe Perches wrote:
On Wed, 2010-09-01 at 17:51 +0200, Julia Lawall wrote:
The file arch/powerpc/platforms/cell/celleb_scc_uhc.c contains the
following function:
static inline int uhc_clkctrl_ready(u32 val)
{
const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBCEN;
On Wed, 2010-09-01 at 17:51 +0200, Julia Lawall wrote:
The file arch/powerpc/platforms/cell/celleb_scc_uhc.c contains the
following function:
static inline int uhc_clkctrl_ready(u32 val)
{
const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBCEN;
return((val mask) == mask);
}
The
On Thu, Aug 05, 2010 at 02:43:25PM +1000, David Gibson wrote:
On Fri, Jun 11, 2010 at 04:59:46PM -0600, Grant Likely wrote:
I've been doing a bit of work on some introductory level documentation
of the flattened device tree. I've got a rough copy up on the
devicetree.org wiki, and I could
On Wed, 1 Sep 2010 18:02:14 +1000
Paul Mackerras pau...@samba.org wrote:
Ah, those references would be from arch/powerpc/lib/sstep.c.
Evidently we need #ifdef CONFIG_PPC_FPU around the emulation of the
floating-point loads and stores.
I tried that yesterday and it didn't help, although maybe
Ok, I didn't catch all the cases the first time :( Since the errors
seemed to come from copy_32.S, I didn't spend much time on sstep.c.
Here is an updated patch the fixes the mtmsrd problem and maps out the
floating point.
Cheers,
Sean
Replace the BOOK3S_64 specific mtmsrd with the generic
On Sep 1, 2010, at 9:43, Grant Likely grant.lik...@secretlab.ca wrote:
In the interest of making driver code easier to write and review,
would you be opposed to a set of patches to remove the ERR_PTR()
pattern from phylib and its users?
Not at all. I was trying to make sure all the
Matthew McClintock wrote:
The first global-utilities node might not contain the rstcr
property, so we should search all the nodes
Signed-off-by: Matthew McClintock m...@freescale.com
Acked-by: Timur Tabi ti...@freescale.com
___
Linuxppc-dev
On Tue, Aug 31, 2010 at 10:48 AM, Julia Lawall ju...@diku.dk wrote:
Add a call to of_node_put in the error handling code following a call to
of_find_compatible_node or of_find_node_by_type.
This patch also substantially reorganizes the error handling code in the
function, to that it is
On 09/01/2010 08:10 AM, Darren Hart wrote:
On 08/31/2010 10:54 PM, Michael Ellerman wrote:
On Tue, 2010-08-31 at 00:12 -0700, Darren Hart wrote:
..
When running with the function plugin I had to stop the trace
immediately before entering start_secondary after an online or my traces
would
On Wed, Sep 1, 2010 at 9:27 AM, David Miller da...@davemloft.net wrote:
From: Grant Likely grant.lik...@secretlab.ca
Date: Wed, 1 Sep 2010 08:42:49 -0600
It seems to me that phylib is one of the cases where the users (the
network drivers) don't actually care about the specific error code
From: Grant Likely grant.lik...@secretlab.ca
Date: Wed, 1 Sep 2010 12:56:29 -0600
The error codes in phylib are almost arbitrary and don't really give
enough information about where the a failure lies. dev_err() is more
useful for debugging.
If it's using bad error codes, that's only
On Wed, 2010-09-01 at 11:47 -0700, Darren Hart wrote:
from tip/rt/2.6.33 causes the preempt_count() to change across the cede
call. This patch appears to prevents the proxy preempt_count assignment
from happening. This non-local-cpu assignment to 0 would cause an
underrun of preempt_count()
On 09/01/2010 12:59 PM, Steven Rostedt wrote:
On Wed, 2010-09-01 at 11:47 -0700, Darren Hart wrote:
from tip/rt/2.6.33 causes the preempt_count() to change across the cede
call. This patch appears to prevents the proxy preempt_count assignment
from happening. This non-local-cpu assignment
I found out what was causing the crash, but still am not there and could use
some direction:
What was happening was that I was not allocating a new SKB to replace the one
in the ring that was being passed up the stack. I have remedied that and am
now having another issue:
Once the ring index
Okay, I think I have all the issues worked out and can now send and receive any
size packet without a hiccup. I have tested this in our system setup as well
with data being sent out to disk and did not see any problems there either
(since it only ever allocates a single page, never more).
Is
Apparently I spoke too soon - sorry about that. I am still getting the error
when I try to write to disk and receive on the network at the same time. Here
is the output:
blastee: page allocation failure. order:1, mode:0x4020
Call Trace:
[ccea9a40] [c0006ef0] show_stack+0x44/0x16c (unreliable)
On Wed, Sep 01, 2010 at 02:42:30PM +0100, Ben Hutchings wrote:
On Wed, 2010-09-01 at 09:43 +0800, Liang Li wrote:
It's common sense that when we should do change to driver ring
desc/buffer etc only after 'stop/shutdown' the device. When we
do change while devices/driver is running, kernel
In message 4c7ebaa8.7030...@us.ibm.com you wrote:
On 09/01/2010 12:59 PM, Steven Rostedt wrote:
On Wed, 2010-09-01 at 11:47 -0700, Darren Hart wrote:
from tip/rt/2.6.33 causes the preempt_count() to change across the cede
call. This patch appears to prevents the proxy preempt_count
On Tue, 2010-08-31 at 15:56 +1000, Benjamin Herrenschmidt wrote:
Hi Linus !
Here's a few small fixes, one is an important fix for a nasty regression
breaking pseries machine running under hypervisor... oops !
I updated this with some embedded fixed from Kumar and a fix for a new
deadlock in
+ /* Check to see if the CPU out of FW already for kexec */
Wow, that comment is shit. The checkin comment in
aef40e87d866355ffd279ab21021de733242d0d5 is much better.
This comment is really confusing to me. I _think_ it is saying that this test
determines if the CPU is done executing
On Thu, 2010-09-02 at 11:02 +1000, Michael Neuling wrote:
We need to call smp_startup_cpu on boot when we the cpus are still in
FW. smp_startup_cpu does this for us on boot.
I'm wondering if we just need to move the test down a bit to make sure
the preempt_count is set. I've not been
On Wed, 2010-09-01 at 22:04 +, Jonathan Haws wrote:
Okay, I think I have all the issues worked out and can now send and
receive any size packet without a hiccup. I have tested this in our
system setup as well with data being sent out to disk and did not see
any problems there either
On Wed, 2010-09-01 at 22:46 +, Jonathan Haws wrote:
Can anyone explain to me why I would be getting this error in the
first place? Why is it failing to allocate a page when there are
pages available? That does not make any sense to me.
order:1
It's failing to allocate -two- pages.
42 matches
Mail list logo
