Re: 64bit kernel is huge

# size vmlinux text data bss dec hex filename 9812942 1982496 1105228 12900666 c4d93a vmlinux ... over kernel releases with pseries_defconfig: text databss dec hex 2.6.32-rc1 9872090 1971184 1105236

Re: linux-next: tree build failure

roel kluin roel.kl...@gmail.com 29.09.09 11:51 On Tue, Sep 29, 2009 at 11:28 AM, Jan Beulich jbeul...@novell.com wrote: Hollis Blanchard 09/29/09 2:00 AM First, I think there is a real bug here, and the code should read like this (to match the comment): /* type has to be known at build

Re: linux-next: tree build failure

Hollis Blanchard holl...@us.ibm.com 30.09.09 01:39 On Tue, 2009-09-29 at 10:28 +0100, Jan Beulich wrote: Hollis Blanchard 09/29/09 2:00 AM First, I think there is a real bug here, and the code should read like this (to match the comment): /* type has to be known at build time for

Re: MPC8536 PCI rescan to discover FPGA

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

Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite

Rex Feany rfe...@mrv.com wrote on 29/09/2009 23:03:31: Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se): Benjamin Herrenschmidt b...@kernel.crashing.org 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

Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite

Rex Feany rfe...@mrv.com wrote on 29/09/2009 23:03:31: Thus spake Joakim Tjernlund (joakim.tjernl...@transmode.se): Benjamin Herrenschmidt b...@kernel.crashing.org wrote on 29/09/2009 10:16:38: hmm, yes. You do get this and mysterious SEGV if you hit the but so

Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite

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 before your

Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite

Rex Feany rfe...@mrv.com 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, found a

Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite

Rex Feany rfe...@mrv.com 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, found a

[PATCH] macintosh: Don't assume i2c device probing always succeeds

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 kh...@linux-fr.org Tested-by: Tim

[PATCH] sound: Don't assume i2c device probing always succeeds

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 s...@alum.mit.edu Signed-off-by: Jean

Re: [patch] powerpc: build modules outside the kernel tree fails, if it was built using O=

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 employed for

Re: 64bit kernel is huge

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

Re: [PATCH] sound: Don't assume i2c device probing always succeeds

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.

Re: [PATCH] sound: Don't assume i2c device probing always succeeds

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 will

Re: [PATCH] sound: Don't assume i2c device probing always succeeds

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 dereference

Re: [PATCH] sound: Don't assume i2c device probing always succeeds

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

Re: [PATCH] sound: Don't assume i2c device probing always succeeds

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 can do

Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite

Rex Feany rfe...@mrv.com 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,

Re: [PATCH] powerpc/5200: add LocalPlus bus FIFO device driver

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,

Re: [PATCH v3 2/3] cpu: Offline state Framework.

On Tue, 15 Sep 2009 17:37:06 +0530 Gautham R Shenoy wrote: Signed-off-by: Gautham R Shenoy e...@in.ibm.com --- Documentation/cpu-hotplug.txt | 22 + drivers/base/cpu.c| 181 +++-- include/linux/cpu.h | 10 ++ 3 files

Re: 64bit kernel is huge

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. ___

Re: [PATCH] powerpc/8xx: fix regression introduced by cache coherency rewrite

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 and top

Re: 64bit kernel is huge

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 9812942

Re: 64bit kernel is huge

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.

Re: 64bit kernel is huge

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 about