At Wed, 30 Sep 2009 18:55:05 +0200,
Jean Delvare wrote:
>
> On Wed, 30 Sep 2009 17:15:49 +0200, Takashi Iwai wrote:
> > Yes, indeed I prefer NULL check because the user can know the error
> > at the right place. I share your concern about the code addition,
> > though :)
> >
> > I already made a
> > 2.6.28 8647080 1699460 780472 11127012a9c8e4
> > 2.6.27 7461663 1505796 774400 9741859 94a623
>
> If you compile 28 with the 27 pseries_config, you lose most of this
> 1.2MB text bloat.
>
> If we remove just FUNCTION_TRACER and STACK_TRACER from 28 we gain back
> a
> 2.6.28 86470801699460 780472 11127012a9c8e4
> 2.6.27 74616631505796 774400 9741859 94a623
If you compile 28 with the 27 pseries_config, you lose most of this
1.2MB text bloat.
If we remove just FUNCTION_TRACER and STACK_TRACER from 28 we gain back
about 600K.
On Mon, 2009-09-28 at 17:45 +1000, Anton Blanchard wrote:
> Hi,
>
> I've found at least one machine that wont boot 2.6.31-rc* with a
> pseries_defconfig. If I move real-base from 0xc0 to 0xd0 it
> boots fine.
>
> # size vmlinux
>text data bss dec hex filename
> 9
> > Had a look at linus tree and there is something I don't understand.
> > Your fix, e0908085fc2391c85b85fb814ae1df377c8e0dcb, fixes a problem
> > that was introduced by 8d30c14cab30d405a05f2aaceda1e9ad57800f36 but
> > 8d30c14cab30d405a05f2aaceda1e9ad57800f36 was included in .31 and .31
> > works
On Wed, 2009-09-30 at 16:01 +1000, Michael Neuling wrote:
> 2.6.30 9221595 1620728 1052812 11895135b5815f
> 2.6.29 9104807 1569840 785292 11459939aedd63
The jump in BSS size is huge... lockdep ?
Ben.
___
Linuxppc-d
The i2c-powermac driver doesn't support arbitrary multi-message I2C
transactions, only SMBus ones. Make it clear by returning an error if
a multi-message I2C transaction is attempted. This is better than only
processing the first message, because most callers won't recover from
the short transactio
On Tue, 15 Sep 2009 17:37:06 +0530 Gautham R Shenoy wrote:
> Signed-off-by: Gautham R Shenoy
> ---
> Documentation/cpu-hotplug.txt | 22 +
> drivers/base/cpu.c| 181
> +++--
> include/linux/cpu.h | 10 ++
> 3 files changed, 204
Hi John:
Cool stuff - Grant's original one also helped me a lot to get Bestcomm
running for me (I use it only for read dma)!
Am 29.09.09 22:43 schrieb(en) John Bonesio:
[snip]
+ * It may be worth experimenting with the ALARM value
to see if
+ * there is a performance impacit. However,
>
> Rex Feany wrote on 30/09/2009 11:00:02:
> >
> > Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
> >
> > > > Ok, I have made some minor tweaks and added debug code in
> > > > do_page_fault(). Would be great if you could try on both
> > > > .31 and top of tree.
> > > >
> > > > Jock
On Wed, 30 Sep 2009 17:15:49 +0200, Takashi Iwai wrote:
> Yes, indeed I prefer NULL check because the user can know the error
> at the right place. I share your concern about the code addition,
> though :)
>
> I already made a patch below, but it's totally untested.
> It'd be helpful if someone c
On Wed, 30 Sep 2009 17:05:11 +0200, Johannes Berg wrote:
> On Wed, 2009-09-30 at 17:00 +0200, Jean Delvare wrote:
>
> > The NULL check of client->driver, if followed by a call to
> > i2c_unregister_device(), would indeed be enough. But unlike the onyx
> > driver which we know we sometimes load err
On Wed, 2009-09-30 at 17:00 +0200, Jean Delvare wrote:
> The NULL check of client->driver, if followed by a call to
> i2c_unregister_device(), would indeed be enough. But unlike the onyx
> driver which we know we sometimes load erroneously, the other drivers
> should never fail.
All of these driv
At Wed, 30 Sep 2009 17:00:06 +0200,
Jean Delvare wrote:
>
> Hi Takashi,
>
> Thanks for the swift reply.
>
> On Wed, 30 Sep 2009 16:13:49 +0200, Takashi Iwai wrote:
> > At Wed, 30 Sep 2009 15:25:42 +0200,
> > Jean Delvare wrote:
> > >
> > > If i2c device probing fails, then there is no driver to
Hi Takashi,
Thanks for the swift reply.
On Wed, 30 Sep 2009 16:13:49 +0200, Takashi Iwai wrote:
> At Wed, 30 Sep 2009 15:25:42 +0200,
> Jean Delvare wrote:
> >
> > If i2c device probing fails, then there is no driver to dereference
> > after calling i2c_new_device(). Stop assuming that probing w
At Wed, 30 Sep 2009 15:25:42 +0200,
Jean Delvare wrote:
>
> If i2c device probing fails, then there is no driver to dereference
> after calling i2c_new_device(). Stop assuming that probing will always
> succeed, to avoid NULL pointer dereferences. We have an easier access
> to the driver anyway.
>
On Monday 28 September 2009, Anton Blanchard wrote:
> 262144 kstat_irqs_all
> 131072 irq_desc
> 16384 irq_stat
>
> Could we dynamically allocate our irq structures?
There were patches floating around for that a few years ago,
but I haven't seen anyone working on it since.
> 131072 lppaca
Hello,
Any news yet?
Any sort of correction needed?
Thank you,
Yuri
On 09/26/2009 04:45 PM, Yuri Frolov wrote:
> Hello, here is a fixed version.
>
> Compile and export arch/powerpc/lib/crtsavres.o in order to fix the
> "arch/powerpc/lib/crtsavres.o not found" error when "O=" option
> is employe
If i2c device probing fails, then there is no driver to dereference
after calling i2c_new_device(). Stop assuming that probing will always
succeed, to avoid NULL pointer dereferences. We have an easier access
to the driver anyway.
Reported-by: Tim Shepard
Signed-off-by: Jean Delvare
Cc: Johannes
If i2c device probing fails, then there is no driver to dereference
after calling i2c_new_device(). Stop assuming that probing will always
succeed, to avoid NULL pointer dereferences. We have an easier access
to the driver anyway.
Signed-off-by: Jean Delvare
Tested-by: Tim Shepard
Cc: Colin Lero
Rex Feany wrote on 30/09/2009 11:00:02:
>
> Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
>
> > > Ok, I have made some minor tweaks and added debug code in
> > > do_page_fault(). Would be great if you could try on both
> > > .31 and top of tree.
> > >
> > > Jocke
> >
> > OOPS, foun
Rex Feany wrote on 30/09/2009 11:00:02:
>
> Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
>
> > > Ok, I have made some minor tweaks and added debug code in
> > > do_page_fault(). Would be great if you could try on both
> > > .31 and top of tree.
> > >
> > > Jocke
> >
> > OOPS, foun
Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
> > Ok, I have made some minor tweaks and added debug code in
> > do_page_fault(). Would be great if you could try on both
> > .31 and top of tree.
> >
> > Jocke
>
> OOPS, found a bug. Use this one instead:
.31 - no change, it worked
>
> Rex Feany wrote on 29/09/2009 23:03:31:
> >
> > Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
> >
> > > Benjamin Herrenschmidt wrote on 29/09/2009
> > > 10:16:38:
> > > >
> > > >
> > > > > hmm, yes. You do get this and mysterious SEGV if you hit the but so
> > > > > does
> >
Rex Feany wrote on 29/09/2009 23:03:31:
>
> Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se):
>
> > Benjamin Herrenschmidt wrote on 29/09/2009
> > 10:16:38:
> > >
> > >
> > > > hmm, yes. You do get this and mysterious SEGV if you hit the but so does
> > > > other bugs too so this is p
Hi, Benjamin
Benjamin Herrenschmidt wrote:
Right. However, in case it's a bit too much work to get
hotswap implemented on the machine, you may still be able
to do something simpler from your platform code, after you've
finished loading the FPGA. I assume the FPGA doesn't contain a
P2P bridge tha
26 matches
Mail list logo
