Re: IDE
Where can I find a pata_of_platform node example ? Sergei Shtylyov a écrit : Arnd Bergmann wrote: Most probably you can use the existing platform drivers: drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c. Create/register a platform device named pata_platform with 2 memory and 1 IRQ resource, and enable one of those drivers. For new boards using a flattened device tree, it should be enough to add a device node for the pata_of_platform driver. Oops, forgot about this one. No wonder, after being knee deep in ARM for several months. :-) MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Call Trace and scary messages on kernel 2.6.27-rc5
Thanks to both Mark and Heiko. On Sep 09 2008, Marc Zyngier wrote: On Mon, 8 Sep 2008 21:47:29 -0300 Rogério Brito [EMAIL PROTECTED] wrote: I just compiled a new 2.6.27-rc5 kernel for my standard Kurobox (an embedded NAS that has an MPC8241 CPU, if I'm not mistaken) and upon booting, I get these scary messages and Call Traces: This is a known problem. Check patch bb23b431db7405f6d79f989ad0236bf6428ba1cb in Linus' tree, it should correct the traces you see. I just downloaded the 2.6.27-rc6 kernel that was updated today and I recompiled things and everything went fine regarding the MTD device. Thank you very much for the informative messages. Regards, Rogério Brito. -- Rogério Brito : [EMAIL PROTECTED],ime.usp}.br : GPG key 1024D/7C2CAEB8 http://www.ime.usp.br/~rbrito : http://meusite.mackenzie.com.br/rbrito Projects: algorithms.berlios.de : lame.sf.net : vrms.alioth.debian.org ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
I saw pata_of_platform source. And when is called pata_of_platform_probe ? 2008/9/11, Sébastien Chrétien [EMAIL PROTECTED]: Where can I find a pata_of_platform node example ? Sergei Shtylyov a écrit : Arnd Bergmann wrote: Most probably you can use the existing platform drivers: drivers/ide/egacy/ide_platform.c or drivers/ata/pata_platform.c. Create/register a platform device named pata_platform with 2 memory and 1 IRQ resource, and enable one of those drivers. For new boards using a flattened device tree, it should be enough to add a device node for the pata_of_platform driver. Oops, forgot about this one. No wonder, after being knee deep in ARM for several months. :-) MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Getting Debian to release the PowerPC port
On Thu, 11 Sep 2008 00:55:14 -0300 Rogério Brito [EMAIL PROTECTED] wrote: Dear Paul, I would like to ask you a few things: * which is the official dtc git repository? I ask it here because dtc.ozlabs.org doesn't seem to work, but this is what is linked to from the page http://ozlabs.org/ and the device-tree-compiler package on Debian has an outdated page (it seems). I already filed a bugreport to that package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497605). git://www.jld.com/software/dtc.git Though the kernel embeds the dtc source in it now, and a stand-alone dtc is not required for kernel builds. * where can I find the people responsible for glibc and gcc/g++ so that I can fill in the empty fields at http://wiki.debian.org/powerpcLennyReleaseRecertification, so that powerpc does not become at risk of not being released? Is the powerpc port cared by some team in special or is it just a unified upstream? PowerPC is supported in the upstream GNU glibc and gcc projects. There is no separate repository for those. The PowerPC maintainers for those projects can be found on the website for glibc (it's Steven Munroe), or in the MAINTAINERS file in gcc. PowerPC is called 'rs6000' in gcc for historical reasons. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: IDE
Hello. Sébastien Chrétien wrote: I saw pata_of_platform source. And when is called pata_of_platform_probe ? Look at the very end of arch/powerpc/boot/dts/mpc8349emitx.dts; probably there are more examples in that directory... MBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Getting Debian to release the PowerPC port
On Thu, Sep 11, 2008 at 07:42:23AM -0400, Josh Boyer wrote: On Thu, 11 Sep 2008 00:55:14 -0300 Rogério Brito [EMAIL PROTECTED] wrote: Dear Paul, I would like to ask you a few things: * which is the official dtc git repository? I ask it here because dtc.ozlabs.org doesn't seem to work, but this is what is linked to from the page http://ozlabs.org/ and the device-tree-compiler package on Debian has an outdated page (it seems). I already filed a bugreport to that package (http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=497605). git://www.jld.com/software/dtc.git Oops, that should be: git://www.jdl.com/software/dtc.git josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/2] ehea: fix phyp debugging typo
Fix typo in ehea_h_query_ehea() which prevents building when DEBUG is on. Signed-off-by: Sebastien Dugue [EMAIL PROTECTED] --- drivers/net/ehea/ehea_phyp.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/net/ehea/ehea_phyp.c b/drivers/net/ehea/ehea_phyp.c index 156eb63..2a33a61 100644 --- a/drivers/net/ehea/ehea_phyp.c +++ b/drivers/net/ehea/ehea_phyp.c @@ -535,7 +535,7 @@ u64 ehea_h_query_ehea(const u64 adapter_handle, void *cb_addr) cb_logaddr, /* R5 */ 0, 0, 0, 0, 0); /* R6-R10 */ #ifdef DEBUG - ehea_dmp(cb_addr, sizeof(struct hcp_query_ehea), hcp_query_ehea); + ehea_dump(cb_addr, sizeof(struct hcp_query_ehea), hcp_query_ehea); #endif return hret; } -- 1.6.0.1.308.gede4c ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/2] ehea: fix mutex and spinlock use
Looks like to me that the ehea_fw_handles.lock mutex and the
ehea_bcmc_regs.lock spinlock are taken much longer than necessary and could
as well be pushed inside the functions that need them
(ehea_update_firmware_handles() and ehea_update_bcmc_registrations())
rather than at each callsite.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
---
drivers/net/ehea/ehea_main.c | 26 --
1 files changed, 4 insertions(+), 22 deletions(-)
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index b70c531..c765ec6 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -219,9 +219,11 @@ static void ehea_update_firmware_handles(void)
}
out_update:
+ mutex_lock(ehea_fw_handles.lock);
kfree(ehea_fw_handles.arr);
ehea_fw_handles.arr = arr;
ehea_fw_handles.num_entries = i;
+ mutex_unlock(ehea_fw_handles.lock);
}
static void ehea_update_bcmc_registrations(void)
@@ -293,9 +295,11 @@ static void ehea_update_bcmc_registrations(void)
}
out_update:
+ spin_lock(ehea_bcmc_regs.lock);
kfree(ehea_bcmc_regs.arr);
ehea_bcmc_regs.arr = arr;
ehea_bcmc_regs.num_entries = i;
+ spin_unlock(ehea_bcmc_regs.lock);
}
static struct net_device_stats *ehea_get_stats(struct net_device *dev)
@@ -1770,8 +1774,6 @@ static int ehea_set_mac_addr(struct net_device *dev, void
*sa)
memcpy(dev-dev_addr, mac_addr-sa_data, dev-addr_len);
- spin_lock(ehea_bcmc_regs.lock);
-
/* Deregister old MAC in pHYP */
if (port-state == EHEA_PORT_UP) {
ret = ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
@@ -1792,7 +1794,6 @@ static int ehea_set_mac_addr(struct net_device *dev, void
*sa)
out_upregs:
ehea_update_bcmc_registrations();
- spin_unlock(ehea_bcmc_regs.lock);
out_free:
kfree(cb0);
out:
@@ -1954,8 +1955,6 @@ static void ehea_set_multicast_list(struct net_device
*dev)
}
ehea_promiscuous(dev, 0);
- spin_lock(ehea_bcmc_regs.lock);
-
if (dev-flags IFF_ALLMULTI) {
ehea_allmulti(dev, 1);
goto out;
@@ -1985,7 +1984,6 @@ static void ehea_set_multicast_list(struct net_device
*dev)
}
out:
ehea_update_bcmc_registrations();
- spin_unlock(ehea_bcmc_regs.lock);
return;
}
@@ -2466,8 +2464,6 @@ static int ehea_up(struct net_device *dev)
if (port-state == EHEA_PORT_UP)
return 0;
- mutex_lock(ehea_fw_handles.lock);
-
ret = ehea_port_res_setup(port, port-num_def_qps,
port-num_add_tx_qps);
if (ret) {
@@ -2504,8 +2500,6 @@ static int ehea_up(struct net_device *dev)
}
}
- spin_lock(ehea_bcmc_regs.lock);
-
ret = ehea_broadcast_reg_helper(port, H_REG_BCMC);
if (ret) {
ret = -EIO;
@@ -2527,10 +2521,8 @@ out:
ehea_info(Failed starting %s. ret=%i, dev-name, ret);
ehea_update_bcmc_registrations();
- spin_unlock(ehea_bcmc_regs.lock);
ehea_update_firmware_handles();
- mutex_unlock(ehea_fw_handles.lock);
return ret;
}
@@ -2580,9 +2572,6 @@ static int ehea_down(struct net_device *dev)
if (port-state == EHEA_PORT_DOWN)
return 0;
- mutex_lock(ehea_fw_handles.lock);
-
- spin_lock(ehea_bcmc_regs.lock);
ehea_drop_multicast_list(dev);
ehea_broadcast_reg_helper(port, H_DEREG_BCMC);
@@ -2591,7 +2580,6 @@ static int ehea_down(struct net_device *dev)
port-state = EHEA_PORT_DOWN;
ehea_update_bcmc_registrations();
- spin_unlock(ehea_bcmc_regs.lock);
ret = ehea_clean_all_portres(port);
if (ret)
@@ -2599,7 +2587,6 @@ static int ehea_down(struct net_device *dev)
dev-name, ret);
ehea_update_firmware_handles();
- mutex_unlock(ehea_fw_handles.lock);
return ret;
}
@@ -3378,7 +3365,6 @@ static int __devinit ehea_probe_adapter(struct of_device
*dev,
ehea_error(Invalid ibmebus device probed);
return -EINVAL;
}
- mutex_lock(ehea_fw_handles.lock);
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
@@ -3462,7 +3448,6 @@ out_free_ad:
out:
ehea_update_firmware_handles();
- mutex_unlock(ehea_fw_handles.lock);
return ret;
}
@@ -3481,8 +3466,6 @@ static int __devexit ehea_remove(struct of_device *dev)
flush_scheduled_work();
- mutex_lock(ehea_fw_handles.lock);
-
ibmebus_free_irq(adapter-neq-attr.ist1, adapter);
tasklet_kill(adapter-neq_tasklet);
@@ -3492,7 +3475,6 @@ static int __devexit ehea_remove(struct of_device *dev)
kfree(adapter);
ehea_update_firmware_handles();
- mutex_unlock(ehea_fw_handles.lock);
return 0;
}
--
1.6.0.1.308.gede4c
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
I was planning to post a similar patch. Good that you already posted it :-) I will try to finish off similar patch for 40x processors. +choice + prompt Page size + depends on 44x PPC32 + default PPC32_4K_PAGES + help + The PAGE_SIZE definition. Increasing the page size may + improve the system performance in some dedicated cases. + If unsure, set it to 4 KB. + You should mention an example of dedicated cases (eg. RAID). I think this help should mention that for page size 256KB, you will need to have a special version of binutils, since the ELF standard mentions page sizes only upto 64KB. -#ifdef CONFIG_PPC_64K_PAGES +#if defined(CONFIG_PPC32_256K_PAGES) +#define PAGE_SHIFT 18 +#elif defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC_64K_PAGES) #define PAGE_SHIFT 16 +#elif defined(CONFIG_PPC32_16K_PAGES) +#define PAGE_SHIFT 14 #else #define PAGE_SHIFT 12 #endif Why should the new defines be inside CONFIG_PPC_64K_PAGES? The definition CONFIG_PPC_64K_PAGES is repeated. Shouldn't these defines be like this: #if defined(CONFIG_PPC32_256K_PAGES) #define PAGE_SHIFT 18 #elif defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC_64K_PAGES) #define PAGE_SHIFT 16 #elif defined(CONFIG_PPC32_16K_PAGES) #define PAGE_SHIFT 14 #else #define PAGE_SHIFT 12 #endif +#elif (PAGE_SHIFT == 14) +/* + * PAGE_SIZE 16K + * PAGE_SHIFT 14 + * PTE_SHIFT 11 + * PMD_SHIFT 25 + */ +#define PPC44x_TLBE_SIZE PPC44x_TLB_16K +#define PPC44x_PGD_OFF_SH 9 /*(32 - PMD_SHIFT + 2)*/ +#define PPC44x_PGD_OFF_M1 23 /*(PMD_SHIFT - 2)*/ +#define PPC44x_PTE_ADD_SH 21 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/ +#define PPC44x_PTE_ADD_M1 18 /*32 - 3 - PTE_SHIFT*/ +#define PPC44x_RPN_M2 17 /*31 - PAGE_SHIFT*/ Please change PPC44x_PGD_OFF_SH to PPC44x_PGD_OFF_SHIFT. SH sounds very confusing. I don't like the MI and M2 names too. Change PPC44x_RPN_M2 to PPC44x_RPN_MASK. Change M1 to MASK in PPC44x_PGD_OFF_M1 and PPC44x_PTE_ADD_M1 . Is there no way a define like #define PPC44x_PGD_OFF_SH (32 - PMD_SHIFT + 2) be used in assembly file. If yes, we can avoid repeating the defines. I think these 44x specific defines should go to asm/mmu-44x.h since I am planning to post a patch for 40x. For those processors, the defines below will changes as: #define PPC44x_PTE_ADD_SH (32 - PMD_SHIFT + PTE_SHIFT + 2) #define PPC44x_PTE_ADD_M1 (32 - 2 - PTE_SHIFT) Since these defines are not generic, they should be put in the mmu specific header file rather than adding a new header file. When 40x processors are supported, the corresponding defines can go to include/asm/mmu-40x.h +#elif (PAGE_SHIFT == 18) +/* + * PAGE_SIZE 256K + * PAGE_SHIFT 18 + * PTE_SHIFT 11 + * PMD_SHIFT 29 + */ +#define PPC44x_TLBE_SIZE PPC44x_TLB_256K +#define PPC44x_PGD_OFF_SH 5 /*(32 - PMD_SHIFT + 2)*/ +#define PPC44x_PGD_OFF_M1 27 /*(PMD_SHIFT - 2)*/ +#define PPC44x_PTE_ADD_SH 17 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/ +#define PPC44x_PTE_ADD_M1 18 /*32 - 3 - PTE_SHIFT*/ +#define PPC44x_RPN_M2 13 /*31 - PAGE_SHIFT*/ For 256KB page size, I cannot understand why PTE_SHIFT is 11. Since each PTE entry is 8 byte, PTE_SHIFT should have been 15. But then there would be no bits in the Effective address for the 1st level PGDIR offset. On what basis PTE_SHIFT of 11 is chosen? This overflow problem happens only for 256KB page size. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH/RFC] 64 bit csum_partial_copy_generic
Did you consider the other alternative? If you work on 32-bit chunks instead of 64-bit chunks (either load them with lwz, or split them after loading with ld), you can add them up with a regular non-carrying add, which isn't serialising like adde; this also allows unrolling the loop (using several accumulators instead of just one). Since your registers are 64-bit, you can sum 16GB of data before ever getting a carry out. Or maybe the bottleneck here is purely the memory bandwidth? I think the main bottleneck is the bandwidth/latency of memory. When I sent the patch out I hadn't thought about eliminating the e from the add with 32 bit chunks. So I went off and tried it today and converting the existing function to use just add instead of adde (since it was only doing 32 bits already) and got 1.5% - 15.7% faster on Power5, which is nice, but was still way behind the new function in every testcase. I then added 1 level of unrolling to that (using 2 accumulators) and got 59% slower to 10% faster on Power5 depending on input. It seems quite a bit slower than I would have expected (I would have expected basically even), but thats what got measured. The comment in the existing function indicates unrolling the loop doesn't help because the bdnz has zero overhead, so I guess the unrolling hurt more than I expected. In any case I have now thought about it and don't think it will work out. Signed-off-by: Joel Schopp[EMAIL PROTECTED] You missed a space there. If at first you don't succeed... Signed-off-by: Joel Schopp [EMAIL PROTECTED] ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hi, prodyut hazarika wrote: +choice + prompt Page size + depends on 44x PPC32 + default PPC32_4K_PAGES + help + The PAGE_SIZE definition. Increasing the page size may + improve the system performance in some dedicated cases. + If unsure, set it to 4 KB. + You should mention an example of dedicated cases (eg. RAID). I think this help should mention that for page size 256KB, you will need to have a special version of binutils, since the ELF standard mentions page sizes only upto 64KB. Agreed. -#ifdef CONFIG_PPC_64K_PAGES +#if defined(CONFIG_PPC32_256K_PAGES) +#define PAGE_SHIFT 18 +#elif defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC_64K_PAGES) #define PAGE_SHIFT 16 +#elif defined(CONFIG_PPC32_16K_PAGES) +#define PAGE_SHIFT 14 #else #define PAGE_SHIFT 12 #endif Why should the new defines be inside CONFIG_PPC_64K_PAGES? The I think you missed first '-' on the first line. definition CONFIG_PPC_64K_PAGES is repeated. Shouldn't these defines be like this: #if defined(CONFIG_PPC32_256K_PAGES) #define PAGE_SHIFT 18 #elif defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC_64K_PAGES) #define PAGE_SHIFT 16 #elif defined(CONFIG_PPC32_16K_PAGES) #define PAGE_SHIFT 14 #else #define PAGE_SHIFT 12 #endif And they do actually :) Please change PPC44x_PGD_OFF_SH to PPC44x_PGD_OFF_SHIFT. SH sounds very confusing. I don't like the MI and M2 names too. Change PPC44x_RPN_M2 to PPC44x_RPN_MASK. Change M1 to MASK in PPC44x_PGD_OFF_M1 and PPC44x_PTE_ADD_M1 . Agreed. Is there no way a define like #define PPC44x_PGD_OFF_SH (32 - PMD_SHIFT + 2) be used in assembly file. If yes, we can avoid repeating the defines. We can use defined like this, problem is that PMD_SHIFT and PTE_SHIFT declared inside #ifndef __ASSEMBLY__ I think these 44x specific defines should go to asm/mmu-44x.h since I Agreed. For 256KB page size, I cannot understand why PTE_SHIFT is 11. Since each PTE entry is 8 byte, PTE_SHIFT should have been 15. But then there would be no bits in the Effective address for the 1st level PGDIR offset. On what basis PTE_SHIFT of 11 is chosen? This overflow problem happens only for 256KB page size. I think Yuri has commented on this already. Any comments on the issues mentioned in introductory message? Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hello, On Thursday, September 11, 2008 you wrote: I was planning to post a similar patch. Good that you already posted it :-) I will try to finish off similar patch for 40x processors. +choice + prompt Page size + depends on 44x PPC32 + default PPC32_4K_PAGES + help + The PAGE_SIZE definition. Increasing the page size may + improve the system performance in some dedicated cases. + If unsure, set it to 4 KB. + You should mention an example of dedicated cases (eg. RAID). ACK. I think this help should mention that for page size 256KB, you will need to have a special version of binutils, since the ELF standard mentions page sizes only upto 64KB. Right. We use ELDK-4.2 for compiling applications to be run on 256K PAGE_SIZE kernel. This toolchain includes necessary changes for ELF_MAXPAGESIZE in binutils/bfd/elf32-ppc.c. -#ifdef CONFIG_PPC_64K_PAGES +#if defined(CONFIG_PPC32_256K_PAGES) +#define PAGE_SHIFT 18 +#elif defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC_64K_PAGES) #define PAGE_SHIFT 16 +#elif defined(CONFIG_PPC32_16K_PAGES) +#define PAGE_SHIFT 14 #else #define PAGE_SHIFT 12 #endif Why should the new defines be inside CONFIG_PPC_64K_PAGES? The definition CONFIG_PPC_64K_PAGES is repeated. We decided to introduce new CONFIG_PPC32_64K_PAGES option to distinguish using 64K pages on PPC32 and PPC64, so PAGE_SHIFT will be defined as 16 when the CONFIG_PPC_64K_PAGES option is set on some PPC64 platform, and as 16 when the CONFIG_PPC32_64K_PAGES option is set on some ppc44x PPC32 platform. Shouldn't these defines be like this: #if defined(CONFIG_PPC32_256K_PAGES) #define PAGE_SHIFT 18 #elif defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC_64K_PAGES) #define PAGE_SHIFT 16 #elif defined(CONFIG_PPC32_16K_PAGES) #define PAGE_SHIFT 14 #else #define PAGE_SHIFT 12 #endif Admittedly, I don't see the difference between your version and Ilya's one. Am I missing something ? +#elif (PAGE_SHIFT == 14) +/* + * PAGE_SIZE 16K + * PAGE_SHIFT 14 + * PTE_SHIFT 11 + * PMD_SHIFT 25 + */ +#define PPC44x_TLBE_SIZE PPC44x_TLB_16K +#define PPC44x_PGD_OFF_SH 9 /*(32 - PMD_SHIFT + 2)*/ +#define PPC44x_PGD_OFF_M1 23 /*(PMD_SHIFT - 2)*/ +#define PPC44x_PTE_ADD_SH 21 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/ +#define PPC44x_PTE_ADD_M1 18 /*32 - 3 - PTE_SHIFT*/ +#define PPC44x_RPN_M2 17 /*31 - PAGE_SHIFT*/ Please change PPC44x_PGD_OFF_SH to PPC44x_PGD_OFF_SHIFT. SH sounds very confusing. I don't like the MI and M2 names too. Change PPC44x_RPN_M2 to PPC44x_RPN_MASK. Change M1 to MASK in PPC44x_PGD_OFF_M1 and PPC44x_PTE_ADD_M1 . Is there no way a define like #define PPC44x_PGD_OFF_SH (32 - PMD_SHIFT + 2) be used in assembly file. If yes, we can avoid repeating the defines. I think these 44x specific defines should go to asm/mmu-44x.h since I am planning to post a patch for 40x. For those processors, the defines below will changes as: #define PPC44x_PTE_ADD_SH (32 - PMD_SHIFT + PTE_SHIFT + 2) #define PPC44x_PTE_ADD_M1 (32 - 2 - PTE_SHIFT) Since these defines are not generic, they should be put in the mmu specific header file rather than adding a new header file. When 40x processors are supported, the corresponding defines can go to include/asm/mmu-40x.h +#elif (PAGE_SHIFT == 18) +/* + * PAGE_SIZE 256K + * PAGE_SHIFT 18 + * PTE_SHIFT 11 + * PMD_SHIFT 29 + */ +#define PPC44x_TLBE_SIZE PPC44x_TLB_256K +#define PPC44x_PGD_OFF_SH 5 /*(32 - PMD_SHIFT + 2)*/ +#define PPC44x_PGD_OFF_M1 27 /*(PMD_SHIFT - 2)*/ +#define PPC44x_PTE_ADD_SH 17 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/ +#define PPC44x_PTE_ADD_M1 18 /*32 - 3 - PTE_SHIFT*/ +#define PPC44x_RPN_M2 13 /*31 - PAGE_SHIFT*/ For 256KB page size, I cannot understand why PTE_SHIFT is 11. Since each PTE entry is 8 byte, PTE_SHIFT should have been 15. But then there would be no bits in the Effective address for the 1st level PGDIR offset. On what basis PTE_SHIFT of 11 is chosen? This overflow problem happens only for 256KB page size. We should use smaller PTE area in address to free some bits for PGDIR part. I guess the only impact this approach has is ineffective usage of memory pages allocated for PTE tables, since having PTE_SHIFT of 11 we use only 1/16 of pages with PTEs. Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
I think you missed first '-' on the first line.
I was not too careful :-)
I think these 44x specific defines should go to asm/mmu-44x.h since I
Agreed.
It would be great to have user-friendly names.
Also moving to the mmu-4xx specific header files hides the changes to 4xx files.
For 256KB page size, I cannot understand why PTE_SHIFT is 11. Since
each PTE entry is 8 byte, PTE_SHIFT should have been 15. But then
there would be no bits in the Effective address for the 1st level
PGDIR offset. On what basis PTE_SHIFT of 11 is chosen? This overflow
problem happens only for 256KB page size.
I think Yuri has commented on this already.
Thanks.
In file arch/powerpc/mm/pgtable_32.c, we have:
#ifdef CONFIG_PTE_64BIT
/* 44x uses an 8kB pgdir because it has 8-byte Linux PTEs. */
#define PGDIR_ORDER 1
#else
#define PGDIR_ORDER 0
#endif
pgd_t *pgd_alloc(struct mm_struct *mm)
{
pgd_t *ret;
ret = (pgd_t *)__get_free_pages(GFP_KERNEL|__GFP_ZERO, PGDIR_ORDER);
return ret;
}
Thus, we allocate 2 pages for 44x processors for PGD. This is needed
only for 4K page.
We are anyway not using the whole 64K or 256K page for the PGD. So
there is no point to waste an additional 64K or 256KB page
Change this to:
#ifdef CONFIG_PTE_64BIT
#if (PAGE_SHIFT == 12)
/* 44x uses an 8kB pgdir because it has 8-byte Linux PTEs. */
#define PGDIR_ORDER 1
#else
#define PGDIR_ORDER 0
#endif
#else
#define PGDIR_ORDER 0
#endif
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
On Thu, Sep 11, 2008 at 10:15:07PM +0400, Yuri Tikhonov wrote: I think this help should mention that for page size 256KB, you will need to have a special version of binutils, since the ELF standard mentions page sizes only upto 64KB. Right. We use ELDK-4.2 for compiling applications to be run on 256K PAGE_SIZE kernel. This toolchain includes necessary changes for ELF_MAXPAGESIZE in binutils/bfd/elf32-ppc.c. Ok, but not everyone does. And I think setting the page size to this should be harder, maybe even dependent upon CONFIG_BROKEN. I need to look over the patch a bit more, but some of the comments you've already gotten seem valid. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
TDM driver
Hi, I am working on Custom MPC8360 Target board. I have four devices connected through the TDM interface. Does any one has written TDM driver for this Processor. I have seen some patches for MPC8323. Is this TDM driver is included in any latest versions of kernel. Regards Surendra ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hi, prodyut hazarika wrote: Also, it would be great if you could point me what changes are necessary to recompile the binutils. I would like to test the 256KB changes on my Canyonlands board. I have got 16KB/64KB working. I think this should be enough: --- binutils-2.16.1/ld/emulparams/elf32ppc.sh.orig2007-08-21 14:18:56.0 +0200 +++ binutils-2.16.1/ld/emulparams/elf32ppc.sh2007-08-21 14:19:42.0 +0200 @@ -8,7 +8,7 @@ GENERATE_PIE_SCRIPT=yes SCRIPT_NAME=elf OUTPUT_FORMAT=elf32-powerpc TEXT_START_ADDR=0x0180 -MAXPAGESIZE=0x1 +MAXPAGESIZE=0x4 COMMONPAGESIZE=0x1000 ARCH=powerpc:common MACHINE= --- binutils-2.16.1/bfd/elf32-ppc.c.orig2007-09-04 13:11:29.0 +0200 +++ binutils-2.16.1/bfd/elf32-ppc.c2007-09-04 13:10:25.0 +0200 @@ -6197,7 +6197,7 @@ #ifdef __QNXTARGET__ #define ELF_MAXPAGESIZE0x1000 #else -#define ELF_MAXPAGESIZE0x1 +#define ELF_MAXPAGESIZE0x4 #endif #define ELF_MINPAGESIZE0x1000 #define elf_info_to_howtoppc_elf_info_to_howto And you need to rebuild the whole RFS with patched binutils of cause. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
/* * Create WS1. This is the faulting address (EPN), * page size, and valid flag. */ - li r11,PPC44x_TLB_VALID | PPC44x_TLB_4K + li r11,PPC44x_TLB_VALID | PPC44x_TLBE_SIZE rlwimi r10,r11,0,20,31 /* Insert valid and page size*/ tlbwe r10,r13,PPC44x_TLB_PAGEID /* Write PAGEID */ Change rlwimi r10,r11,0,20,31 /* Insert valid and page size*/ to rlwimi r10,r11,0,PPC44x_PTE_ADD_M1,31 /* Insert valid and page size*/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hi,
prodyut hazarika wrote:
In file arch/powerpc/mm/pgtable_32.c, we have:
#ifdef CONFIG_PTE_64BIT
/* 44x uses an 8kB pgdir because it has 8-byte Linux PTEs. */
#define PGDIR_ORDER 1
#else
#define PGDIR_ORDER 0
#endif
pgd_t *pgd_alloc(struct mm_struct *mm)
{
pgd_t *ret;
ret = (pgd_t *)__get_free_pages(GFP_KERNEL|__GFP_ZERO, PGDIR_ORDER);
return ret;
}
Thus, we allocate 2 pages for 44x processors for PGD. This is needed
only for 4K page.
We are anyway not using the whole 64K or 256K page for the PGD. So
there is no point to waste an additional 64K or 256KB page
Ok. Not sure I'm right but I think 16K case doesn't need second page
too. (PGDIR_SHIFT=25, so sizeof(pgd_t)(32-PGDIR_SHIFT) 16KB)
Change this to:
#ifdef CONFIG_PTE_64BIT
#if (PAGE_SHIFT == 12)
I think #ifdef CONFIG_PTE_64BIT is a little bit confusing here...
Actually PGDIR_ORDER should be something like max(32 + 2 - PGDIR_SHIFT
- PAGE_SHIFT, 0)
/* 44x uses an 8kB pgdir because it has 8-byte Linux PTEs. */
#define PGDIR_ORDER 1
#else
#define PGDIR_ORDER 0
#endif
#else
#define PGDIR_ORDER 0
#endif
Yuri, any comments?
Regards, Ilya.
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hello Prodyut, Thanks for your comments. Some answers below. On Friday, September 12, 2008 you wrote: /* * Create WS1. This is the faulting address (EPN), * page size, and valid flag. */ - li r11,PPC44x_TLB_VALID | PPC44x_TLB_4K + li r11,PPC44x_TLB_VALID | PPC44x_TLBE_SIZE rlwimi r10,r11,0,20,31 /* Insert valid and page size*/ tlbwe r10,r13,PPC44x_TLB_PAGEID /* Write PAGEID */ Change rlwimi r10,r11,0,20,31 /* Insert valid and page size*/ to rlwimi r10,r11,0,PPC44x_PTE_ADD_M1,31 /* Insert valid and page size*/ Agree. We'll fix this. I guess this works for us, because we used the large EPN mask here which covered more bits in EPN field of TLB entries, than it was required for 16/64/256K PAGE_SIZE cases: TLB Word 0 / bits 0..21: EPN (Effective Page Number) [from 4 to 22 bits] TLB Word 0 / bit 22 : V (Valid bit) [1 bit] TLB Word 0 / bits 24..27 : SIZE (Page Size) [4 bits] Thus, doing 'rlwimi' we masked our V/SIZE bits and cleared EPN for all 4/16/64/256K PAGE_SIZE cases. Regards, Yuri -- Yuri Tikhonov, Senior Software Engineer Emcraft Systems, www.emcraft.com ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hello Josh, Josh Boyer wrote: Ok, but not everyone does. And I think setting the page size to this should be harder, maybe even dependent upon CONFIG_BROKEN. Well, we are violating ELF standard here... CONFIG_BROKEN seems to be adequate for me. I need to look over the patch a bit more, but some of the comments you've already gotten seem valid. I'll address them and post updated patch in a few days. Regards, Ilya. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re[2]: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
Hi Ilya,
On Friday, September 12, 2008 you wrote:
Hi,
prodyut hazarika wrote:
In file arch/powerpc/mm/pgtable_32.c, we have:
#ifdef CONFIG_PTE_64BIT
/* 44x uses an 8kB pgdir because it has 8-byte Linux PTEs. */
#define PGDIR_ORDER 1
#else
#define PGDIR_ORDER 0
#endif
pgd_t *pgd_alloc(struct mm_struct *mm)
{
pgd_t *ret;
ret = (pgd_t *)__get_free_pages(GFP_KERNEL|__GFP_ZERO, PGDIR_ORDER);
return ret;
}
Thus, we allocate 2 pages for 44x processors for PGD. This is needed
only for 4K page.
We are anyway not using the whole 64K or 256K page for the PGD. So
there is no point to waste an additional 64K or 256KB page
Ok. Not sure I'm right but I think 16K case doesn't need second page
too. (PGDIR_SHIFT=25, so sizeof(pgd_t)(32-PGDIR_SHIFT) 16KB)
ACK, no need need in a second page when working with 16K pages.
Prodyut's approach addresses this too, but ...
Change this to:
#ifdef CONFIG_PTE_64BIT
#if (PAGE_SHIFT == 12)
I think #ifdef CONFIG_PTE_64BIT is a little bit confusing here...
Actually PGDIR_ORDER should be something like max(32 + 2 - PGDIR_SHIFT
- PAGE_SHIFT, 0)
/* 44x uses an 8kB pgdir because it has 8-byte Linux PTEs. */
#define PGDIR_ORDER 1
#else
#define PGDIR_ORDER 0
#endif
#else
#define PGDIR_ORDER 0
#endif
Yuri, any comments?
... as for me, I like your approach more.
Regards, Yuri
--
Yuri Tikhonov, Senior Software Engineer
Emcraft Systems, www.emcraft.com
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: TQM8349 and ARCH = powerpc
On Wed, Sep 10, 2008 at 04:12:22PM +0200, Oliver Rutsch wrote:
Hi again,
u-boot assigns the IMMR to 0xff40 in TQM834x.h, whereas the device
tree you picked has it at 0xe000 (it's defined in the soc node).
Don't forget to match up the PCI addresses too. patches welcome, of
course (we don't have tqm boards).
So I modified the dts to match the IMMRMBAR and the pci section at
0xff40. In U-Boot I disabled the PCI_CONFIG because I don't need the
PCI bus. But the result is always the same. It looks like the kernel
stops booting at an earlier stage.
I hope it's OK to post my current tqm8349.dts here:
Any suggestions are welcome.
Thanks and bye,
/dts-v1/;
[snip]
[EMAIL PROTECTED] {
device_type = watchdog;
Drop this device_type.
compatible = mpc83xx_wdt;
reg = 0x200 0x100;
};
[snip]
[EMAIL PROTECTED] {
compatible = fsl-usb2-mph;
reg = 0x22000 0x1000;
#address-cells = 1;
#size-cells = 0;
interrupt-parent = ipic;
interrupts = 39 0x8;
phy_type = ulpi;
port1;
Yuck.. is this 'port1' thing in the binding? It's a terrible property
name...
};
[snip]
enet0: [EMAIL PROTECTED] {
cell-index = 0;
device_type = network;
model = TSEC;
compatible = gianfar;
Didn't someone finally get around to rewriting the gianfar binding
with a better compatible string?
reg = 0x24000 0x1000;
local-mac-address = [ 00 00 00 00 00 00 ];
interrupts = 32 0x8 33 0x8 34 0x8;
interrupt-parent = ipic;
phy-handle = phy0;
linux,network-index = 0;
linux,network-index shouldn't be necessary any more.
};
[snip]
pci0: [EMAIL PROTECTED] {
cell-index = 1;
I don't think cell-index belongs here.
interrupt-map-mask = 0xf800 0x0 0x0 0x7;
interrupt-map =
/* IDSEL 0x10 - SATA */
0x8000 0x0 0x0 0x1 ipic 22 0x8 /* SATA_INTA */
;
interrupt-parent = ipic;
interrupts = 66 0x8;
bus-range = 0x0 0x0;
ranges = 0x4200 0x0 0x8000 0x8000 0x0 0x1000
0x0200 0x0 0x9000 0x9000 0x0 0x1000
0x0100 0x0 0x 0xe200 0x0 0x0100;
clock-frequency = ;
#interrupt-cells = 1;
#size-cells = 2;
#address-cells = 3;
reg = 0xff408500 0x100;
compatible = fsl,mpc8349-pci;
device_type = pci;
};
[EMAIL PROTECTED] {
#address-cells = 2;
#size-cells = 1;
compatible = fsl,mpc8349e-localbus,
fsl,pq2pro-localbus;
reg = 0xff405000 0xd8;
ranges = 0x3 0x0 0xf000 0x210;
};
};
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
On Fri, 12 Sep 2008 03:38:39 +0400 Ilya Yanok [EMAIL PROTECTED] wrote: Hello Josh, Josh Boyer wrote: Ok, but not everyone does. And I think setting the page size to this should be harder, maybe even dependent upon CONFIG_BROKEN. Well, we are violating ELF standard here... CONFIG_BROKEN seems to be adequate for me. Right, that was my thinking as well. You can add an explanation for that in the help text. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] powerpc: add support for PAGE_SIZEs greater than 4KB for
On Thu, Sep 11, 2008 at 01:53:06AM +0400, Ilya Yanok wrote:
This patch adds support for page sizes bigger than 4KB (16KB/64KB/256KB) on
PPC 44x.
[snip]
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 587da5e..ca93157 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -413,6 +413,29 @@ config PPC_64K_PAGES
while on hardware with such support, it will be used to map
normal application pages.
+choice
+ prompt Page size
+ depends on 44x PPC32
+ default PPC32_4K_PAGES
+ help
+ The PAGE_SIZE definition. Increasing the page size may
+ improve the system performance in some dedicated cases.
+ If unsure, set it to 4 KB.
+
+config PPC32_4K_PAGES
+ bool 4k page size
+
+config PPC32_16K_PAGES
+ bool 16k page size
+
+config PPC32_64K_PAGES
+ bool 64k page size
+
+config PPC32_256K_PAGES
+ bool 256k page size
+
I don't see any reason to have a separate set of config options for 32
and 64-bit. Just make the once choice, but only have the individual
pagesize options enabled on machines that support them.
[snip]
index e088545..1de90b4 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -15,12 +15,17 @@
#include asm/types.h
/*
- * On PPC32 page size is 4K. For PPC64 we support either 4K or 64K software
+ * On regular PPC32 page size is 4K (but we support 4K/16K/64K/256K pages
+ * on PPC44x). For PPC64 we support either 4K or 64K software
* page size. When using 64K pages however, whether we are really supporting
* 64K pages in HW or not is irrelevant to those definitions.
*/
-#ifdef CONFIG_PPC_64K_PAGES
+#if defined(CONFIG_PPC32_256K_PAGES)
+#define PAGE_SHIFT 18
+#elif defined(CONFIG_PPC32_64K_PAGES) || defined(CONFIG_PPC_64K_PAGES)
#define PAGE_SHIFT 16
+#elif defined(CONFIG_PPC32_16K_PAGES)
+#define PAGE_SHIFT 14
#else
#define PAGE_SHIFT 12
#endif
@@ -140,11 +145,19 @@ typedef struct { pte_basic_t pte; } pte_t;
/* 64k pages additionally define a bigger real PTE type that gathers
* the second half part of the PTE for pseudo 64k pages
*/
+#ifdef CONFIG_PPC64
#ifdef CONFIG_PPC_64K_PAGES
typedef struct { pte_t pte; unsigned long hidx; } real_pte_t;
#else
typedef struct { pte_t pte; } real_pte_t;
#endif
+#else
+#ifdef CONFIG_PPC32_4K_PAGES
+typedef struct { pte_t pte; } real_pte_t;
+#else
+typedef struct { pte_t pte; unsigned long hidx; } real_pte_t;
I don't think you should need a real_pte_t type for the 32-bit
implementation. It's just there because of how we implement
64k granularity page allocation on hardware that only does 4k
translations.
[snip]
diff --git a/arch/powerpc/include/asm/page_32.h
b/arch/powerpc/include/asm/page_32.h
index ebfae53..d176270 100644
--- a/arch/powerpc/include/asm/page_32.h
+++ b/arch/powerpc/include/asm/page_32.h
@@ -20,7 +20,11 @@
*/
#ifdef CONFIG_PTE_64BIT
typedef unsigned long long pte_basic_t;
+#ifdef CONFIG_PPC32_256K_PAGES
+#define PTE_SHIFT(PAGE_SHIFT - 7)
This doesn't look right. You should be eliding one of the levels of
page table if you don't need it, rather than leaving the bottom level
PTE page largely empty.
[snip]
+#if (PAGE_SHIFT == 12)
+/*
+ * PAGE_SIZE 4K
+ * PAGE_SHIFT 12
+ * PTE_SHIFT 9
+ * PMD_SHIFT 21
+ */
+#define PPC44x_TLBE_SIZE PPC44x_TLB_4K
+#define PPC44x_PGD_OFF_SH13 /*(32 - PMD_SHIFT + 2)*/
+#define PPC44x_PGD_OFF_M119 /*(PMD_SHIFT - 2)*/
+#define PPC44x_PTE_ADD_SH23 /*32 - PMD_SHIFT + PTE_SHIFT + 3*/
+#define PPC44x_PTE_ADD_M120 /*32 - 3 - PTE_SHIFT*/
+#define PPC44x_RPN_M219 /*31 - PAGE_SHIFT*/
Uh.. you have the formulae for these things right there in the
comments, so why aren't you using those and avoiding this nasty
multiway ifdef...
[snip]
diff --git a/arch/powerpc/include/asm/thread_info.h
b/arch/powerpc/include/asm/thread_info.h
index 9665a26..4e7cd1f 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -15,8 +15,12 @@
#ifdef CONFIG_PPC64
#define THREAD_SHIFT 14
#else
+#if defined(CONFIG_PPC32_256K_PAGES)
+#define THREAD_SHIFT 15
Hrm.. more peculiar special cases for 256K pages. I think it might be
clearer if you split the patch into one which supports page sizes up
to 64k, then another that does the extra hacks for 256k pages.
[snip]
@@ -391,12 +392,14 @@ interrupt_base:
rlwimi r13,r12,10,30,30
/* Load the PTE */
- rlwinm r12, r10, 13, 19, 29/* Compute pgdir/pmd offset */
+ /* Compute pgdir/pmd offset */
+ rlwinm r12, r10, PPC44x_PGD_OFF_SH, PPC44x_PGD_OFF_M1, 29
I agree with others that these constants need better names. Or even
derive the values from PMD_SHIFT or whatnot right here inline, rather
than defining special constants.
[snip]
diff --git a/arch/powerpc/kernel/head_booke.h
Re: [PATCH] mm: fix ENTRIES_PER_PAGEPAGE overflow with 256KB pages
On Thu, Sep 11, 2008 at 01:53:07AM +0400, Ilya Yanok wrote: ENTRIES_PER_PAGEPAGE define in mm/shmem.c becomes zero if page size is 256KB. This patch fixes this. This looks.. dubious. You're making a change to generic code for a powerpc feature. Plus it's not entirely clear that simply increasing the variable size is a good fix here. Again, I think since this is a 256k page special case it will simplify things to get the =64k stuff first, then handle this in another patch. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] mm: fix ENTRIES_PER_PAGEPAGE overflow with 256KB pages
On Thu, Sep 11, 2008 at 01:53:07AM +0400, Ilya Yanok wrote: ENTRIES_PER_PAGEPAGE define in mm/shmem.c becomes zero if page size is 256KB. This patch fixes this. This looks.. dubious. You're making a change to generic code for a powerpc feature. Plus it's not entirely clear that simply increasing the variable size is a good fix here. Again, I think since this is a 256k page special case it will simplify things to get the =64k stuff first, then handle this in another patch. 16KB/64KB patch would not really need any hacks like the 256KB. The changes for 16/64KB can be totally hidden under 4xx specific files. So I too think that this patch should be split into 2 patches. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mpc5200: 2.6.3-rt7: Timer subsystem WARN_ON_ONCE causing large latencies
Hi, Here is dmesg output and config file for my powerpc 5200 based embedded device. This device boots up with the default time 01-01-1970, and when a date -s is tried to set the current time, this WARN_ON_ONCE appears. This causes a very large latency and causes the board to completely lock up for more than a minute or so. regards /prady [ cut here ] Badness at kernel/time/clockevents.c:88 NIP: c0046ba8 LR: c00475ec CTR: c000dd80 REGS: c31d3d20 TRAP: 0700 Not tainted (2.6.26.3-rt7) MSR: 00021032 ME,IR,DR CR: 88084288 XER: TASK = c319e9a0[1505] 'ptpd' THREAD: c31d2000 GPR00: 0001 c31d3dd0 c319e9a0 c02fe2f0 0036 03fa9ffc c02d6070 GPR08: 079364da c030 03fa9ffc 0b59b709 9672a1c0 100258c4 100b7308 GPR16: 100bdc28 c31d3e18 GPR24: c4653600 3b9ac9ff c31d3e10 c02fe2f0 b7394ab9 0f5607c9 c31d3e10 c02fe2f0 NIP [c0046ba8] clockevents_program_event+0x1d8/0x248 LR [c00475ec] tick_program_event+0x7c/0x10c Call Trace: [c31d3dd0] [c003fca0] ktime_get+0x1c/0x44 (unreliable) [c31d3e00] [c00475ec] tick_program_event+0x7c/0x10c [c31d3e50] [c003f9d0] hrtimer_force_reprogram+0xa0/0xe4 [c31d3e60] [c0040a18] retrigger_next_event+0x88/0xc0 [c31d3ea0] [c0040a78] clock_was_set+0x20/0x3c [c31d3eb0] [c00434dc] do_settimeofday+0x188/0x1d0 [c31d3ee0] [c0028fac] do_sys_settimeofday+0x74/0x1b4 [c31d3f00] [c0029610] sys_settimeofday+0x178/0x17c [c31d3f40] [c0010f9c] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff35dbc LR = 0x1000b64c Instruction dump: 3860ffc2 4bd0 54e0083c 2126001f 7c004830 7d1d3430 7c1deb78 4b60 3d20c030 8009c470 2080 7c040114 0f00 2f80 419eff98 3801 -- # # Automatically generated make config: don't edit # Linux kernel version: 2.6.26.3-rt7 # Tue Sep 9 18:41:00 2008 # # CONFIG_PPC64 is not set # # Processor support # CONFIG_6xx=y # CONFIG_PPC_85xx is not set # CONFIG_PPC_8xx is not set # CONFIG_40x is not set # CONFIG_44x is not set # CONFIG_E200 is not set CONFIG_PPC_FPU=y # CONFIG_ALTIVEC is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_STD_MMU_32=y # CONFIG_PPC_MM_SLICES is not set # CONFIG_SMP is not set CONFIG_PPC32=y CONFIG_WORD_SIZE=32 CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y # CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y # CONFIG_ARCH_NO_VIRT_TO_BUS is not set CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_NVRAM=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y # CONFIG_PPC_UDBG_16550 is not set # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y CONFIG_DEFAULT_UIMAGE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_LOG_BUF_SHIFT=14 # CONFIG_CGROUPS is not set CONFIG_GROUP_SCHED=y CONFIG_FAIR_GROUP_SCHED=y # CONFIG_RT_GROUP_SCHED is not set CONFIG_USER_SCHED=y # CONFIG_CGROUP_SCHED is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y # CONFIG_RELAY is not set # CONFIG_NAMESPACES is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_RADIX_TREE_CONCURRENT is not set CONFIG_EMBEDDED=y # CONFIG_SYSCTL_SYSCALL is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_COMPAT_BRK=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y # CONFIG_EPOLL is not set CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_TRACEPOINTS=y # CONFIG_MARKERS is not set CONFIG_HAVE_OPROFILE=y # CONFIG_KPROBES is not set CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y # CONFIG_HAVE_DMA_ATTRS is not set CONFIG_PROC_PAGE_MONITOR=y CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set # CONFIG_MODVERSIONS is not set #
