Dear Rupjyoti, Prodyut, Mark,
two weeks ago I wrote:
In message <20100818205646.57783157...@gemini.denx.de> you wrote:
>
> drivers/ata/sata_dwc_460ex.c fails to build in current mainline:
...
> Do you have any hints how to fix that?
Any comments or ideas how to fix this?
Best regards,
Wolfgan
On 09/01/2010 09:06 PM, Steven Rostedt wrote:
> 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
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.
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 (s
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
> + /* 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 executin
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 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 pree
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, ke
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)
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 t
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
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 assig
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
From: Grant Likely
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 indicative of a bug in
phylib.
On Wed, Sep 1, 2010 at 9:27 AM, David Miller wrote:
> From: Grant Likely
> 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 dri
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 tra
On Tue, Aug 31, 2010 at 10:48 AM, Julia Lawall 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 possible first
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
Acked-by: Timur Tabi
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.
On Sep 1, 2010, at 9:43, Grant Likely 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 information was available,
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 MT
On Wed, 1 Sep 2010 18:02:14 +1000
Paul Mackerras 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 I forgot to
ma
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
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);
>
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_U
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 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
> Cc: Grant Likely
> Cc: linuxppc-dev@lists.ozlabs.org
applied, thanks.
g.
> ---
> arch/powerpc/platforms/512x/clock.c |2 +-
> 1 f
From: Grant Likely
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 the function failed,
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
> > wrote:
> > > On Tue, Aug 31, 2010 at 02:03:44AM -0600, Grant Likely wrote:
> > >> On Tue, Aug 24, 2010 at 01:26
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 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
Grant Likely schrieb:
> On Tue, Aug 31, 2010 at 10:16 AM, Vasiliy Kulikov 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", strle
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 va
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] = ring->rx_p
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
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?
___
L
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
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
a
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 CO
>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
>wrote:
>>>
>>> On Jun 18, 2010, at 1:24 AM, Li Yang wrote:
>>>
Fixes the following compile problem on E500 platforms:
arch/powerpc/s
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 mos
41 matches
Mail list logo
