Bug#483489: linux-2.6: Optional powerpc64 patches for PS3
Bastian Blank wrote: > tags 483489 wontfix > thanks > > On Wed, May 28, 2008 at 05:26:37PM -0700, Geoff Levand wrote: >> Attached are two patches against the debian linux-2.6-2.6.25 >> sources that would be nice to apply for the PS3. > > Please send them to [EMAIL PROTECTED] Also you have to use that way to > fix the following error, after it have been applied to Linus' tree: > | ERROR: "fb_mode_option" [drivers/ps3/ps3av_mod.ko] undefined! > > Tagging as wontfix for now. Just FYI, I submitted the memory leak and undefined symbol bugs for the stable kernel. I don't think the vmemmap-variable-page-size patch is suitable as it is quite intrusive and is not really a 'critical' fix. -Geoff -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#439006: [EMAIL PROTECTED]: Bug#483489: linux-2.6: Optional powerpc64 patches for PS3]
Hi technical comittee, .. I write to you again about this topic, to show you another case of disfunctioning of the kernel team politic regarding patches, and one i am not even involved with, so you have no excuse to ignore this issue because i am involved. Geoff Levand, who is one of the sony upstream developers of the sony PS3 linux port, recently did the work to provide a configuration file to the kernel team for adding PS3 support to our kernels, which is the first step in proper debian support on PS3, since d-i work kind of depends on this. Furthermore, he proposed two patches which seems to be important, as you can see below, and bastian blank refused them asking him to go upstream first. Well, this is not some random guy providing some patch he got from some random location, but the sony team is actively bringing those patches upstream. Furthermore, the nature of those patches, which i would consider vital for the useability of the memory starved PS3, doesn't justify not applying them. One is there to allow the PS3 to make use of the full memory of the PS3, and not be limited to 80MB, the second fixes a memory leak. It is clear that the kernel team is not able to have a rationale decision on this topic, and is blocked unthinkingly because of some "send upstream first" discourse who is too rigid and arrogant. If they don't have enough manpower to handle this correctly, then maybe they should not expulse people of their team without any reasonable justification, and i would gladly be handling this. So, i hope that the technical committee will have the decency and basic politeness to at least aknowledge this bug report now that it hurts others than just me, and take this very serious issue in its hand, and take a decision, as its responsabilities dictate. Sadly, Sven Luther - Forwarded message from Geoff Levand <[EMAIL PROTECTED]> ----- Subject: Bug#483489: linux-2.6: Optional powerpc64 patches for PS3 Message-ID: <[EMAIL PROTECTED]> Date: Wed, 28 May 2008 17:26:37 -0700 From: Geoff Levand <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Package: linux-2.6 Version: 2.6.25 Severity: normal Tags: patch Attached are two patches against the debian linux-2.6-2.6.25 sources that would be nice to apply for the PS3. - debian-powerpc64-vmemmap-variable-page-size.diff This patch changes vmemmap to use a different region (region 0xf) of the address space whose page size can be dynamically configured at boot. The problem with the current approach of always using 16M pages is that it's not well suited to machines that have small amounts of memory such as small partitions on pseries, or PS3's. In fact, on the PS3, failure to allocate the 16M page backing vmmemmap tends to prevent hotplugging the HV's "additional" memory, thus limiting the available memory even more, from my experience down to something like 80M total, which makes it really not very useable. - debian-powerpc64-ps3-gelic-wireless-fix-memory-leak.patch This fixes the bug that the I/O buffer is not freed at the driver removal. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Kernel: Linux 2.6.25-3-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Add the patch powerpc-vmemmap-variable-page-size.diff to the debian linux-2.6-2.6.25 source tree. This is a backport of the patch merged into 2.6.26. --- debian/patches/bugfix/powerpc/powerpc-vmemmap-variable-page-size.diff | 214 ++ debian/patches/series/1 |1 2 files changed, 215 insertions(+) --- /dev/null +++ b/debian/patches/bugfix/powerpc/powerpc-vmemmap-variable-page-size.diff @@ -0,0 +1,214 @@ +ps3-linux-stable-2.6.25 + o Backported to 2.6.25.4 + o Removed DEBUG's + +Subject: [RFC] [PATCH] vmemmap fixes to use smaller pages + +From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> + +This patch changes vmemmap to use a different region (region 0xf) of the +address space whose page size can be dynamically configured at boot. + +The problem with the current approach of always using 16M pages is that +it's not well suited to machines that have small amounts of memory such +as small partitions on pseries, or PS3's. + +In fact, on the PS3, failure to allocate the 16M page backing vmmemmap +tends to prevent hotplugging the HV's "additional" memory, thus limiting +the available memory even more, from my experience down to something +like 80M total, which makes it really not very useable. + +The logic used by my match to choose the vmemmap page size is: + + - If 16M pages are available and there's 1G or more RAM at boot, use that size. + - Else if 64K pages are available, use that + - Else use 4K pages + +--- + ar
Bug#483489: linux-2.6: Optional powerpc64 patches for PS3
On Thu, May 29, 2008 at 09:13:25AM +0200, Bastian Blank wrote: > tags 483489 wontfix > thanks > > On Wed, May 28, 2008 at 05:26:37PM -0700, Geoff Levand wrote: > > Attached are two patches against the debian linux-2.6-2.6.25 > > sources that would be nice to apply for the PS3. > > Please send them to [EMAIL PROTECTED] Also you have to use that way to > fix the following error, after it have been applied to Linus' tree: > | ERROR: "fb_mode_option" [drivers/ps3/ps3av_mod.ko] undefined! > > Tagging as wontfix for now. Bastian, what justification is there for not applying at lease the second patch ? Its a damn memory leak, how can you not accept it, when it is the upstream of those patches who propose them. Note that Geoff didn't just send you the whole patchset, but cherry picked two patches he considered important for the useability of the PS3, which is already memory starved, so limiting it further to 80MB and not fixing a memory leak is *NOT* acceptable. Sadly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#483489: linux-2.6: Optional powerpc64 patches for PS3
tags 483489 wontfix thanks On Wed, May 28, 2008 at 05:26:37PM -0700, Geoff Levand wrote: > Attached are two patches against the debian linux-2.6-2.6.25 > sources that would be nice to apply for the PS3. Please send them to [EMAIL PROTECTED] Also you have to use that way to fix the following error, after it have been applied to Linus' tree: | ERROR: "fb_mode_option" [drivers/ps3/ps3av_mod.ko] undefined! Tagging as wontfix for now. Bastian -- Leave bigotry in your quarters; there's no room for it on the bridge. -- Kirk, "Balance of Terror", stardate 1709.2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#483489: linux-2.6: Optional powerpc64 patches for PS3
Package: linux-2.6 Version: 2.6.25 Severity: normal Tags: patch Attached are two patches against the debian linux-2.6-2.6.25 sources that would be nice to apply for the PS3. - debian-powerpc64-vmemmap-variable-page-size.diff This patch changes vmemmap to use a different region (region 0xf) of the address space whose page size can be dynamically configured at boot. The problem with the current approach of always using 16M pages is that it's not well suited to machines that have small amounts of memory such as small partitions on pseries, or PS3's. In fact, on the PS3, failure to allocate the 16M page backing vmmemmap tends to prevent hotplugging the HV's "additional" memory, thus limiting the available memory even more, from my experience down to something like 80M total, which makes it really not very useable. - debian-powerpc64-ps3-gelic-wireless-fix-memory-leak.patch This fixes the bug that the I/O buffer is not freed at the driver removal. -- System Information: Debian Release: lenny/sid APT prefers testing APT policy: (500, 'testing') Architecture: powerpc (ppc64) Kernel: Linux 2.6.25-3-powerpc64 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Add the patch powerpc-vmemmap-variable-page-size.diff to the debian linux-2.6-2.6.25 source tree. This is a backport of the patch merged into 2.6.26. --- debian/patches/bugfix/powerpc/powerpc-vmemmap-variable-page-size.diff | 214 ++ debian/patches/series/1 |1 2 files changed, 215 insertions(+) --- /dev/null +++ b/debian/patches/bugfix/powerpc/powerpc-vmemmap-variable-page-size.diff @@ -0,0 +1,214 @@ +ps3-linux-stable-2.6.25 + o Backported to 2.6.25.4 + o Removed DEBUG's + +Subject: [RFC] [PATCH] vmemmap fixes to use smaller pages + +From: Benjamin Herrenschmidt <[EMAIL PROTECTED]> + +This patch changes vmemmap to use a different region (region 0xf) of the +address space whose page size can be dynamically configured at boot. + +The problem with the current approach of always using 16M pages is that +it's not well suited to machines that have small amounts of memory such +as small partitions on pseries, or PS3's. + +In fact, on the PS3, failure to allocate the 16M page backing vmmemmap +tends to prevent hotplugging the HV's "additional" memory, thus limiting +the available memory even more, from my experience down to something +like 80M total, which makes it really not very useable. + +The logic used by my match to choose the vmemmap page size is: + + - If 16M pages are available and there's 1G or more RAM at boot, use that size. + - Else if 64K pages are available, use that + - Else use 4K pages + +--- + arch/powerpc/mm/hash_utils_64.c | 28 ++-- + arch/powerpc/mm/init_64.c |8 + arch/powerpc/mm/slb.c | 14 +- + arch/powerpc/mm/slb_low.S | 16 +--- + include/asm-powerpc/mmu-hash64.h|1 + + include/asm-powerpc/pgtable-ppc64.h | 10 +- + 6 files changed, 62 insertions(+), 15 deletions(-) + +--- a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c +@@ -93,6 +93,9 @@ unsigned long htab_hash_mask; + int mmu_linear_psize = MMU_PAGE_4K; + int mmu_virtual_psize = MMU_PAGE_4K; + int mmu_vmalloc_psize = MMU_PAGE_4K; ++#ifdef CONFIG_SPARSEMEM_VMEMMAP ++int mmu_vmemmap_psize = MMU_PAGE_4K; ++#endif + int mmu_io_psize = MMU_PAGE_4K; + int mmu_kernel_ssize = MMU_SEGSIZE_256M; + int mmu_highuser_ssize = MMU_SEGSIZE_256M; +@@ -363,11 +366,32 @@ static void __init htab_init_page_sizes( + } + #endif /* CONFIG_PPC_64K_PAGES */ + ++#ifdef CONFIG_SPARSEMEM_VMEMMAP ++ /* We try to use 16M pages for vmemmap if that is supported ++ * and we have at least 1G of RAM at boot ++ */ ++ if (mmu_psize_defs[MMU_PAGE_16M].shift && ++ lmb_phys_mem_size() >= 0x4000) ++ mmu_vmemmap_psize = MMU_PAGE_16M; ++ else if (mmu_psize_defs[MMU_PAGE_64K].shift) ++ mmu_vmemmap_psize = MMU_PAGE_64K; ++ else ++ mmu_vmemmap_psize = MMU_PAGE_4K; ++#endif /* CONFIG_SPARSEMEM_VMEMMAP */ ++ + printk(KERN_DEBUG "Page orders: linear mapping = %d, " +- "virtual = %d, io = %d\n", ++ "virtual = %d, io = %d" ++#ifdef CONFIG_SPARSEMEM_VMEMMAP ++ ", vmemmap = %d" ++#endif ++ "\n", + mmu_psize_defs[mmu_linear_psize].shift, + mmu_psize_defs[mmu_virtual_psize].shift, +- mmu_psize_defs[mmu_io_psize].shift); ++ mmu_psize_defs[mmu_io_psize].shift ++#ifdef CONFIG_SPARSEMEM_VMEMMAP ++ ,mmu_psize_defs[mmu_vmemmap_psize].shift ++#endif ++ ); + + #ifdef CONFIG_HUGETLB_PAGE + /* Init large page size. Currently, we pick 16M or 1M depending +--- a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c +@@ -208,12 +208,12 @@ int __meminit vmemmap_populated(unsigned + } + + int __meminit vmemmap_populate(struct page *start_page, +
