Jens Axboe wrote:
Can you see if this fixes it for you?
diff --git a/block/cfq-iosched.c b/block/cfq-iosched.c
index e01b103..64de5c0 100644
--- a/block/cfq-iosched.c
+++ b/block/cfq-iosched.c
@@ -1654,6 +1654,7 @@ retry:
}
RB_CLEAR_NODE(&cfqq->rb_node);
+
Tony Breeds wrote:
> On Wed, Apr 08, 2009 at 01:47:36PM -0500, Nathan Lynch wrote:
>
> > I think I had some reason for doing it this way, but I'm drawing a
> > blank right now.
> >
> > In the meantime, can someone post the warnings that gcc emits for
> > cacheinfo.c, as well as the gcc version?
On Thu, Apr 09, 2009 at 10:31:12AM -0400, Josh Boyer wrote:
> On Thu, Apr 09, 2009 at 09:28:23AM -0500, Kumar Gala wrote:
> >
> > On Apr 9, 2009, at 8:52 AM, Subrata Modak wrote:
> >
> >> Observed the following build error:
> >>
> >> CC drivers/net/ibm_newemac/core.o
> >> drivers/net/ibm_newem
On Mon, 6 Apr 2009 22:01:15 +0100 (BST)
Hugh Dickins wrote:
> Now that shmem's divisions by zero and SHMEM_MAX_BYTES are fixed,
> let powerpc 256kB pages coexist with CONFIG_SHMEM again.
>
> Signed-off-by: Hugh Dickins
> ---
> Added linuxppc-dev and some other Cc's for this 3/3: sorry
> if you
Unfortunately -Wno-uninitialized also suppresses the warnings that
point
to real bugs.
It's a double-edged sword, yes. Warnings are always like that:
if the compiler could know that something _is_ wrong for certain,
it wouldn't need a warning (it would use an error, instead -- and
it does do
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-
variable. But I
thought this was about uninitialised var warnings? -Wno-
uninitialized
for that one.
If you are asking for a GCC option that will warn for all suspect
cases
_except_ for the ones where it is obvious to you there is
On Fri, 10 Apr 2009 08:45:53 +1000 Tony Breeds wrote:
>
> On Fri, Apr 10, 2009 at 12:46:06AM +0200, Segher Boessenkool wrote:
>
> > -Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable. But I
> > thought this was about uninitialised var warnings? -Wno-uninitialized
> > for that one
On Fri, Apr 10, 2009 at 12:46:06AM +0200, Segher Boessenkool wrote:
> -Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable. But I
> thought this was about uninitialised var warnings? -Wno-uninitialized
> for that one.
> If you are asking for a GCC option that will warn for all susp
Gah, gcc sucks. It should just not warn in these cases where it
doesn't
know wth is going on.
I don't think you'll get any arguments. it only there was a -
Wnowarnunused!
-Wno-unused or -Wno-unused-pparameter and/or -Wno-unused-variable.
But I
thought this was about uninitialised var w
Thanks for your help.
This was a kernel setup issue, I had forgotten to strip the debug information
out of my new libraries and my initramfs was too large.
I believe the zImage was decompressing onto itself, thats why it was stuck at
the "now booting." I probably could have fixed it by changing
On Thu, Apr 09 2009, Jens Axboe wrote:
> On Thu, Apr 09 2009, Sachin Sant wrote:
> > I had Next 09 booted on a powerpc box and was compiling a kernel.
> > That's when i ran into this oops.
> >
> > Unable to handle kernel paging request for data at address 0x0010.
> > Faulting instruction addres
On Thu, Apr 09 2009, Sachin Sant wrote:
> I had Next 09 booted on a powerpc box and was compiling a kernel.
> That's when i ran into this oops.
>
> Unable to handle kernel paging request for data at address 0x0010.
> Faulting instruction address: 0xc02ee1b0...
> 0:mon> e
Hi Kevin,
This doesn't look like an NPTL problem to me. It appears you have
rebuilt the kernel, and your new kernel has a problem booting on the
board. I would check the configuration options you have enabled in the
kernel, and I would check that xparameters.h (older kernel) or the
device-tre
> > -Original Message-
> > From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> > Sent: Wednesday, April 08, 2009 7:52 PM
> > To: John Linn
> > Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com;
> > linuxppc-dev@ozlabs.org;
> > linux-fbdev-de...@lists.sourceforge.net;
> > ako
> -Original Message-
> From: Dale Farnsworth [mailto:d...@farnsworth.org]
> Sent: Thursday, April 09, 2009 9:36 AM
> To: John Linn; linuxppc-dev@ozlabs.org
> Subject: Re: [PATCH] Xilinx : Framebuffer Driver: Add PLB
> support (non-DCR)
>
> > > -Original Message-
> > > From: Step
ee1b0 LR: c02e14d0 CTR: c02e35ac
REGS: c000f20d2940 TRAP: 0300 Tainted: GF
(2.6.30-rc1-next-20090409)
MSR: 80009032 CR: 44024448 XER: 0001
DAR: 0010, DSISR: 4000
TASK = c000f9346a00[3684] 'sh' THREAD: c00
Observed the following build errors:
Building modules, stage 2.
MODPOST 549 modules
ERROR: ".lro_receive_skb" [drivers/net/pasemi_mac_driver.ko] undefined!
ERROR: ".lro_flush_all" [drivers/net/pasemi_mac_driver.ko] undefined!
WARNING: modpost: Found 8 section mismatch(es).
To see full details buil
On Thu, Apr 9, 2009 at 12:32 AM, Jeff Garzik wrote:
> 3) As a result, Timur's 'ahci' is no longer receiving interrupts. Presumably
> this means that BOTH of the following conditions are true
>
> a) INTX is disabled
> b) MSI is not available
>
> Today I am thinking we should either re
On Thu, 9 Apr 2009, Subrata Modak wrote:
> Observed the following error:
>
> BLD FW drivers/net/wan/wanxlfw.inc
> /bin/sh: as68k: command not found
> make[3]: *** [drivers/net/wan/wanxlfw.inc] Error 127
> make[2]: *** [drivers/net/wan] Error 2
> make[1]: *** [drivers/net] Error 2
> make: *** [dri
2009/4/9 Kumar Gala :
> Can someone look at converting drivers/net/fs_enet over to the new
> net_device_ops.
>
> Dave,
>
> Are you willing to take such a patch in for .30? Otherwise we need to add a
> select COMPAT_NET_DEV_OPS in Kconfig for this driver (and any others that
> might not have been c
On Thu, 2009-04-09 at 18:46 +0400, Alexander Beregalov wrote:
> Reported-by: Subrata Modak
> Signed-off-by: Alexander Beregalov
Thanks. Adding Sachin in Cc:
Regards--
Subrata
> ---
>
>
> drivers/net/fs_enet/fs_enet-main.c | 27 +--
> 1 files changed, 17 insertions(
Reported-by: Subrata Modak
Signed-off-by: Alexander Beregalov
---
drivers/net/fs_enet/fs_enet-main.c | 27 +--
1 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/drivers/net/fs_enet/fs_enet-main.c
b/drivers/net/fs_enet/fs_enet-main.c
index b037ce9..a9c
Forgot one at the end, sorry.
> -Original Message-
> From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com]
> Sent: Thursday, April 09, 2009 6:47 AM
> To: John Linn
> Cc: grant.lik...@secretlab.ca; linuxppc-dev@ozlabs.org;
> linux-fbdev-de...@lists.sourceforge.net;
> akonova...@ru.mvista.
> -Original Message-
> From: Grant Likely [mailto:grant.lik...@secretlab.ca]
> Sent: Thursday, April 09, 2009 8:35 AM
> To: Roderick Colenbrander
> Cc: Josh Boyer; linux-fbdev-de...@lists.sourceforge.net;
> adap...@gmail.com; Suneel Garapati; linuxppc-dev@ozlabs.org;
> akonova...@ru.m
On Thu, Apr 9, 2009 at 7:06 AM, Roderick Colenbrander
wrote:
>
> On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer
> wrote:
>>
>> On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
>> >From: Suneel <[mailto:suneel.garap...@xilinx.com]>
>> >
>> >Added support for the new xps tft controller.
>> >
> -Original Message-
> From: Josh Boyer [mailto:jwbo...@linux.vnet.ibm.com]
> Sent: Thursday, April 09, 2009 6:47 AM
> To: John Linn
> Cc: grant.lik...@secretlab.ca; linuxppc-dev@ozlabs.org;
> linux-fbdev-de...@lists.sourceforge.net;
> akonova...@ru.mvista.com; adap...@gmail.com; Suneel
On Thu, Apr 09, 2009 at 04:06:56PM +0200, Roderick Colenbrander wrote:
>On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer wrote:
>> > #define NUM_REGS 2
>> > #define REG_FB_ADDR 0
>> >@@ -112,6 +123,11 @@ struct xilinxfb_drvdata {
>> >
>> > struct fb_info info; /* FB driver info re
On Thu, Apr 09, 2009 at 09:28:23AM -0500, Kumar Gala wrote:
>
> On Apr 9, 2009, at 8:52 AM, Subrata Modak wrote:
>
>> Observed the following build error:
>>
>> CC drivers/net/ibm_newemac/core.o
>> drivers/net/ibm_newemac/core.c: In function ‘emac_probe’:
>> drivers/net/ibm_newemac/core.c:2831:
On Thu, Apr 9, 2009 at 7:16 AM, John Linn wrote:
>> -Original Message-
>> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
>> Sent: Wednesday, April 08, 2009 7:52 PM
>> To: John Linn
>> Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com;
>> linuxppc-dev@ozlabs.org;
>> linux-fbd
On Apr 9, 2009, at 8:52 AM, Subrata Modak wrote:
Observed the following build error:
CC drivers/net/ibm_newemac/core.o
drivers/net/ibm_newemac/core.c: In function ‘emac_probe’:
drivers/net/ibm_newemac/core.c:2831: error: ‘struct net_device’ has no
member named ‘open’
drivers/net/ibm_newem
On Apr 9, 2009, at 8:50 AM, Subrata Modak wrote:
Observed the following build error:
drivers/net/fs_enet/fs_enet-main.c: In function ‘fs_enet_probe’:
drivers/net/fs_enet/fs_enet-main.c:1096: error: ‘struct net_device’
has
no member named ‘open’
drivers/net/fs_enet/fs_enet-main.c:1097: error
Can someone look at converting drivers/net/fs_enet over to the new
net_device_ops.
Dave,
Are you willing to take such a patch in for .30? Otherwise we need to
add a select COMPAT_NET_DEV_OPS in Kconfig for this driver (and any
others that might not have been converted over). drivers/net/
Hi Johannes,
On Thu, 09 Apr 2009 14:34:44 +0200, Johannes Berg wrote:
> > My new approach doesn't auto-load anything. Here we go, what you think?
> > This time there is no logic change, I'm really only turning legacy code
> > into new-style i2c code (basically calling i2c_new_device() instead of
>
On Thu, Apr 9, 2009 at 2:46 PM, Josh Boyer wrote:
> On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
> >From: Suneel <[mailto:suneel.garap...@xilinx.com]>
> >
> >Added support for the new xps tft controller.
> >
> >The new core has PLB interface support in addition to existing
> >DCR int
> -Original Message-
> From: Stephen Rothwell [mailto:s...@canb.auug.org.au]
> Sent: Wednesday, April 08, 2009 7:52 PM
> To: John Linn
> Cc: grant.lik...@secretlab.ca; jwbo...@linux.vnet.ibm.com;
> linuxppc-dev@ozlabs.org;
> linux-fbdev-de...@lists.sourceforge.net;
> akonova...@ru.mvist
Observed the following build error:
CC drivers/net/ibm_newemac/core.o
drivers/net/ibm_newemac/core.c: In function ‘emac_probe’:
drivers/net/ibm_newemac/core.c:2831: error: ‘struct net_device’ has no
member named ‘open’
drivers/net/ibm_newemac/core.c:2834: error: ‘struct net_device’ has no
mem
Observed the following build error:
CC arch/powerpc/platforms/pasemi/setup.o
arch/powerpc/platforms/pasemi/setup.c:48: error: redefinition of
‘smp_send_stop’
include/linux/smp.h:125: error: previous definition of ‘smp_send_stop’
was here
make[2]: *** [arch/powerpc/platforms/pasemi/setup.o] Er
Observed the following build error:
arch/powerpc/platforms/pseries/dtl.c: In function ‘dtl_init’:
arch/powerpc/platforms/pseries/dtl.c:238: error: implicit declaration of
function ‘firmware_has_feature’
arch/powerpc/platforms/pseries/dtl.c:238: error: ‘FW_FEATURE_SPLPAR’
undeclared (first use in t
Observed the following build error:
drivers/net/fs_enet/fs_enet-main.c: In function ‘fs_enet_probe’:
drivers/net/fs_enet/fs_enet-main.c:1096: error: ‘struct net_device’ has
no member named ‘open’
drivers/net/fs_enet/fs_enet-main.c:1097: error: ‘struct net_device’ has
no member named ‘hard_start_xm
On Wed, Apr 08, 2009 at 03:11:25PM -0600, John Linn wrote:
>From: Suneel <[mailto:suneel.garap...@xilinx.com]>
>
>Added support for the new xps tft controller.
>
>The new core has PLB interface support in addition to existing
>DCR interface.
>
>The driver has been modified to support this new core
Hi Jean,
> OK, I understand how it works now, thanks for pointing me to the
> relevant piece of code. It's easier to modify the code when you
> understand the current logic ;)
:)
> The idea is to assign fixed i2c bus numbers to the relevant i2c buses,
> and declare the i2c devices connected to e
Hi Johannes,
On Thu, 09 Apr 2009 09:44:49 +0200, Johannes Berg wrote:
> > Can you please point me to the layout fabric / aoa fabric? I'd like to
> > understand how it works. Then I may be able to rewrite my patch
> > completely differently.
>
> That's in sound/aoa/fabric/layout.c
OK, I understan
Wolfgang Grandegger wrote:
> Kumar Gala wrote:
>> On Apr 8, 2009, at 2:25 AM, Wolfgang Grandegger wrote:
>>
So I'm a bit concerned with the output we now get:
mpc-i2c fffe03000.i2c: clock 0 Hz (dfsrr=16 fdr=49)
why 0? is that right?
>>> This is the backward compatibility mo
I am using VIA VT6421 pci chipset..
when i am connecting my 250GB SATA drive i am getting this dump it seems
that interrupt from UIC0(interrupt 25) wich is hooked to PCI_INTA is not
getting cleared and because of this interrupt is not getting cleared it is
calling interrupt handler 10
--
View this message in context:
http://www.nabble.com/problem-with-yellowstone-tp22967168p22967168.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/l
Hi Jean!
> Yes, "probing" would be duplicated if we had to support more than one
> bus. But as far as I can see, the onyx and tas devices can only be
> found on i2c-powermac buses, so this shouldn't be an issue. And there
> isn't really any probing going on, it's really only a matter of walking
>
Hi all,
Seems like there are some NAPI changes not being (correctly) applied to the
MPC5200 FEC driver...
[ 1319.265289] [ cut here ]
[ 1319.274699] kernel BUG at .../arch/powerpc/include/asm/dma-mapping.h:164!
[ 1319.297488] Oops: Exception in kernel mode, sig: 5 [#1]
[
I agree. Every processor(SOC) has unique of setting inbound window. What I
noticed is Inbound regions are created big enough to map whole DDR region. And
uses physical address of ram as a source/destination address. For example if a
PCI-E SATA card wants to do DMA transfers to DDR region. It w
On Wed, Apr 08, 2009 at 03:53:55PM -0500, Kumar Gala wrote:
> I was wondering if we have anything that tracks regions associated with
> the "inbound" side of a pci_bus.
>
> What I mean is on embedded PPC we have window/mapping registers for both
> inbound (accessing memory on the SoC) and outboun
49 matches
Mail list logo
