From mpjohn at us.ibm.com Wed Dec 1 08:34:29 2004 From: mpjohn at us.ibm.com (Maynard Johnson) Date: Tue, 30 Nov 2004 15:34:29 -0600 Subject: power4 performance counters Message-ID: > > Is there a publicly available document that specifies the events > countable on power4 performance counters? I found POWER4.evs on an AIX > box (part of pmapi library), but I would like to write my own code that > accesses those counters on linux, and incorporating that information > probably violates IBM copyright. > > Thanks, > Igor I've been told by those responsible for the PMU documentation for PowerPC that they are keenly aware of the need and that they will be working to fix this problem with publicly available doc, but I wouldn't expect that it will be very soon. In the meantime, it may interest you to know that my team has just completed a port of OProfile to ppc64, supporting Power4, 5, and 970. It's currently available at the OProfile website (http://oprofile.sourceforge.net/news/) in their CVS (not included in their latest release). This will be included in RHEL 4 and (probably) SLES 9 SP1. Additionally, we're starting work on porting PAPI (http://icl.cs.utk.edu/papi/index.html) to ppc64. If you still would like access to the currently confidential PMU doc, get with me offline from this mailing list and I can probably hook you up with the right resources. Maynard Johnson LTC Power Linux Toolchain 507-253-2650 From igor at cs.wisc.edu Fri Dec 3 03:59:49 2004 From: igor at cs.wisc.edu (Igor Grobman) Date: Thu, 2 Dec 2004 10:59:49 -0600 (CST) Subject: power4 performance counters In-Reply-To: <20041129214914.GD17540@krispykreme.ozlabs.ibm.com> References: <20041129214914.GD17540@krispykreme.ozlabs.ibm.com> Message-ID: Anton, Thanks for the oprofile and 970 Book IV pointers. They proved very useful. On Tue, 30 Nov 2004, Anton Blanchard wrote: > > > Let me know if you get stuck. Just out of interest, are you planning to > work on one of the performance counter packages (eg pmapi, perfctr) I am working on a kernel instrumentation/profiling tool called kerninst. I mentioned it on this list before. Basically, we provide a mechanism to place code snippets in any arbitrary point, while the kernel is running (no recompile/reboot is needed). I am looking to provide primitives for using performance counters inside the instrumentation. Hence, my question. See http://www.paradyn.org/html/kerninst.html. ppc64 release is coming real soon now. -Igor From miltonm at bga.com Fri Dec 3 16:46:24 2004 From: miltonm at bga.com (Milton Miller) Date: Thu, 2 Dec 2004 23:46:24 -0600 Subject: PPC64: EEH Recovery (Revised) Message-ID: Well, I was going to suggest you allocate the bars in the cnode that you use to save the device tree with, in the function eeh_save_bars. Then I realized that eeh_save_bars doesn't do anything except walk the tree allocating nodes, finding matching pci devices to read and copy pci_dev-> is_bridge. The actuall save was done at eeh_late_init. Which means eeh_save_bars is misnamed. You walk the list in recursive decent, creating a node each time you go. You restore the bars in the same recursive decent order, only instead of walking device_node you walk the tree that you saved. Why can you not just alloate a struct list and a "is_bridge" field, do the same walk adding to the end of the list in save then restore by walking the list forwards with list_for_each_safe ? See, the restore code just became linear. milton From schwab at suse.de Sun Dec 5 03:34:45 2004 From: schwab at suse.de (Andreas Schwab) Date: Sat, 04 Dec 2004 17:34:45 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac Message-ID: The 2.6.10-rc3 kernel does not boot on PowerMac G5, the last thing I see is "smp_core99_kick_cpu done". Any idea where I should start looking? Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From anton at samba.org Sun Dec 5 05:20:43 2004 From: anton at samba.org (Anton Blanchard) Date: Sun, 5 Dec 2004 05:20:43 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: Message-ID: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> > The 2.6.10-rc3 kernel does not boot on PowerMac G5, the last thing I see > is "smp_core99_kick_cpu done". Any idea where I should start looking? At a guess, does backing out this patch help? Anton -- From: Olof Johansson Below patch changes the early CPU spinup code to be based on physical CPU ID instead of logical. This will make it possible to kexec off of a different cpu than 0, for example after it's been hot-unplugged. The booted cpu will still be mapped as logical cpu 0, since there's various stuff in the early boot that assumes logical boot cpuid is 0. Also, it expands the kexec boot param structure to allow the booted physical cpuid to be passed in. This includes bumping the version number to 2 for backwards compat. Signed-off-by: Olof Johansson Signed-off-by: Anton Blanchard diff -puN arch/ppc64/kernel/asm-offsets.c~boot-cpuid arch/ppc64/kernel/asm-offsets.c --- linux-2.5/arch/ppc64/kernel/asm-offsets.c~boot-cpuid 2004-11-16 12:41:26.546908234 -0600 +++ linux-2.5-olof/arch/ppc64/kernel/asm-offsets.c 2004-11-16 13:24:49.372405523 -0600 @@ -103,6 +103,7 @@ int main(void) DEFINE(PACA_EXDSI, offsetof(struct paca_struct, exdsi)); DEFINE(PACAEMERGSP, offsetof(struct paca_struct, emergency_sp)); DEFINE(PACALPPACA, offsetof(struct paca_struct, lppaca)); + DEFINE(PACAHWCPUID, offsetof(struct paca_struct, hw_cpu_id)); DEFINE(LPPACASRR0, offsetof(struct ItLpPaca, xSavedSrr0)); DEFINE(LPPACASRR1, offsetof(struct ItLpPaca, xSavedSrr1)); DEFINE(LPPACAANYINT, offsetof(struct ItLpPaca, xIntDword.xAnyInt)); diff -puN arch/ppc64/kernel/head.S~boot-cpuid arch/ppc64/kernel/head.S --- linux-2.5/arch/ppc64/kernel/head.S~boot-cpuid 2004-11-16 12:41:26.548908679 -0600 +++ linux-2.5-olof/arch/ppc64/kernel/head.S 2004-11-16 13:20:02.404741718 -0600 @@ -26,6 +26,7 @@ #define SECONDARY_PROCESSORS #include +#include #include #include #include @@ -1192,7 +1193,7 @@ unrecov_slb: /* * On pSeries, secondary processors spin in the following code. - * At entry, r3 = this processor's number (in Linux terms, not hardware). + * At entry, r3 = this processor's number (physical cpu id) */ _GLOBAL(pseries_secondary_smp_init) mr r24,r3 @@ -1204,13 +1205,27 @@ _GLOBAL(pseries_secondary_smp_init) /* Copy some CPU settings from CPU 0 */ bl .__restore_cpu_setup - /* Set up a paca value for this processor. */ - LOADADDR(r5, paca) /* Get base vaddr of paca array */ - mulli r13,r24,PACA_SIZE /* Calculate vaddr of right paca */ - add r13,r13,r5 /* for this processor. */ - mtspr SPRG3,r13 /* Save vaddr of paca in SPRG3 */ -1: - HMT_LOW + /* Set up a paca value for this processor. Since we have the + * physical cpu id in r3, we need to search the pacas to find + * which logical id maps to our physical one. + */ + LOADADDR(r13, paca) /* Get base vaddr of paca array */ + li r5,0 /* logical cpu id */ +1: lhz r6,PACAHWCPUID(r13) /* Load HW procid from paca */ + cmpw r6,r24 /* Compare to our id */ + beq 2f + addi r13,r13,PACA_SIZE /* Loop to next PACA on miss */ + addi r5,r5,1 + cmpwi r5,NR_CPUS + blt 1b + +99: HMT_LOW /* Couldn't find our CPU id */ + b 99b + +2: mtspr SPRG3,r13 /* Save vaddr of paca in SPRG3 */ + /* From now on, r24 is expected to be logica cpuid */ + mr r24,r5 +3: HMT_LOW lbz r23,PACAPROCSTART(r13) /* Test if this processor should */ /* start. */ sync @@ -1225,7 +1240,7 @@ _GLOBAL(pseries_secondary_smp_init) bne .__secondary_start #endif #endif - b 1b /* Loop until told to go */ + b 3b /* Loop until told to go */ #ifdef CONFIG_PPC_ISERIES _STATIC(__start_initialization_iSeries) /* Clear out the BSS */ @@ -1921,19 +1936,6 @@ _STATIC(start_here_multiplatform) bl .__save_cpu_setup sync -#ifdef CONFIG_SMP - /* All secondary cpus are now spinning on a common - * spinloop, release them all now so they can start - * to spin on their individual paca spinloops. - * For non SMP kernels, the secondary cpus never - * get out of the common spinloop. - */ - li r3,1 - LOADADDR(r5,__secondary_hold_spinloop) - tophys(r4,r5) - std r3,0(r4) -#endif - /* Setup a valid physical PACA pointer in SPRG3 for early_setup * note that boot_cpuid can always be 0 nowadays since there is * nowhere it can be initialized differently before we reach this @@ -2131,6 +2133,22 @@ _GLOBAL(hmt_start_secondary) blr #endif +#if defined(CONFIG_SMP) && !defined(CONFIG_PPC_ISERIES) +_GLOBAL(smp_release_cpus) + /* All secondary cpus are spinning on a common + * spinloop, release them all now so they can start + * to spin on their individual paca spinloops. + * For non SMP kernels, the secondary cpus never + * get out of the common spinloop. + */ + li r3,1 + LOADADDR(r5,__secondary_hold_spinloop) + std r3,0(r5) + sync + blr +#endif /* CONFIG_SMP && !CONFIG_PPC_ISERIES */ + + /* * We put a few things here that have to be page-aligned. * This stuff goes at the beginning of the data segment, diff -puN arch/ppc64/kernel/pacaData.c~boot-cpuid arch/ppc64/kernel/pacaData.c --- linux-2.5/arch/ppc64/kernel/pacaData.c~boot-cpuid 2004-11-16 12:41:26.551909346 -0600 +++ linux-2.5-olof/arch/ppc64/kernel/pacaData.c 2004-11-16 12:41:26.572914016 -0600 @@ -58,6 +58,7 @@ extern unsigned long __toc_start; .stab_real = (asrr), /* Real pointer to segment table */ \ .stab_addr = (asrv), /* Virt pointer to segment table */ \ .cpu_start = (start), /* Processor start */ \ + .hw_cpu_id = 0xffff, \ .lppaca = { \ .xDesc = 0xd397d781, /* "LpPa" */ \ .xSize = sizeof(struct ItLpPaca), \ diff -puN arch/ppc64/kernel/prom.c~boot-cpuid arch/ppc64/kernel/prom.c --- linux-2.5/arch/ppc64/kernel/prom.c~boot-cpuid 2004-11-16 12:41:26.554910013 -0600 +++ linux-2.5-olof/arch/ppc64/kernel/prom.c 2004-11-16 12:41:26.573914239 -0600 @@ -853,10 +853,19 @@ static int __init early_init_dt_scan_cpu } } - /* Check if it's the boot-cpu, set it's hw index in paca now */ - if (get_flat_dt_prop(node, "linux,boot-cpu", NULL) != NULL) { - u32 *prop = get_flat_dt_prop(node, "reg", NULL); - paca[0].hw_cpu_id = prop == NULL ? 0 : *prop; + if (initial_boot_params && initial_boot_params->version >= 2) { + /* version 2 of the kexec param format adds the phys cpuid + * of booted proc. + */ + boot_cpuid_phys = initial_boot_params->boot_cpuid_phys; + boot_cpuid = 0; + } else { + /* Check if it's the boot-cpu, set it's hw index in paca now */ + if (get_flat_dt_prop(node, "linux,boot-cpu", NULL) != NULL) { + u32 *prop = get_flat_dt_prop(node, "reg", NULL); + set_hard_smp_processor_id(0, prop == NULL ? 0 : *prop); + boot_cpuid_phys = get_hard_smp_processor_id(0); + } } return 0; diff -puN arch/ppc64/kernel/prom_init.c~boot-cpuid arch/ppc64/kernel/prom_init.c --- linux-2.5/arch/ppc64/kernel/prom_init.c~boot-cpuid 2004-11-16 12:41:26.556910458 -0600 +++ linux-2.5-olof/arch/ppc64/kernel/prom_init.c 2004-11-16 12:41:26.575914683 -0600 @@ -992,13 +992,13 @@ static void __init prom_hold_cpus(void) /* Primary Thread of non-boot cpu */ prom_printf("%x : starting cpu hw idx %x... ", cpuid, reg); call_prom("start-cpu", 3, 0, node, - secondary_hold, cpuid); + secondary_hold, reg); for ( i = 0 ; (i < 100000000) && (*acknowledge == ((unsigned long)-1)); i++ ) mb(); - if (*acknowledge == cpuid) { + if (*acknowledge == reg) { prom_printf("done\n"); /* We have to get every CPU out of OF, * even if we never start it. */ diff -puN arch/ppc64/kernel/setup.c~boot-cpuid arch/ppc64/kernel/setup.c --- linux-2.5/arch/ppc64/kernel/setup.c~boot-cpuid 2004-11-16 12:41:26.559911125 -0600 +++ linux-2.5-olof/arch/ppc64/kernel/setup.c 2004-11-16 13:22:53.060669846 -0600 @@ -99,6 +99,8 @@ extern void htab_initialize(void); extern void early_init_devtree(void *flat_dt); extern void unflatten_device_tree(void); +extern void smp_release_cpus(void); + unsigned long decr_overclock = 1; unsigned long decr_overclock_proc0 = 1; unsigned long decr_overclock_set = 0; @@ -106,6 +108,7 @@ unsigned long decr_overclock_proc0_set = int have_of = 1; int boot_cpuid = 0; +int boot_cpuid_phys = 0; dev_t boot_dev; /* @@ -242,6 +245,7 @@ static void __init setup_cpu_maps(void) { struct device_node *dn = NULL; int cpu = 0; + int swap_cpuid = 0; check_smt_enabled(); @@ -266,11 +270,23 @@ static void __init setup_cpu_maps(void) cpu_set(cpu, cpu_present_map); set_hard_smp_processor_id(cpu, intserv[j]); } + if (intserv[j] == boot_cpuid_phys) + swap_cpuid = cpu; cpu_set(cpu, cpu_possible_map); cpu++; } } + /* Swap CPU id 0 with boot_cpuid_phys, so we can always assume that + * boot cpu is logical 0. + */ + if (boot_cpuid_phys != get_hard_smp_processor_id(0)) { + u32 tmp; + tmp = get_hard_smp_processor_id(0); + set_hard_smp_processor_id(0, boot_cpuid_phys); + set_hard_smp_processor_id(swap_cpuid, tmp); + } + /* * On pSeries LPAR, we need to know how many cpus * could possibly be added to this partition. @@ -630,6 +646,11 @@ void __init setup_system(void) * iSeries has already initialized the cpu maps at this point. */ setup_cpu_maps(); + + /* Release secondary cpus out of their spinloops at 0x60 now that + * we can map physical -> logical CPU ids + */ + smp_release_cpus(); #endif /* defined(CONFIG_SMP) && !defined(CONFIG_PPC_ISERIES) */ printk("Starting Linux PPC64 %s\n", UTS_RELEASE); diff -puN include/asm-ppc64/prom.h~boot-cpuid include/asm-ppc64/prom.h --- linux-2.5/include/asm-ppc64/prom.h~boot-cpuid 2004-11-16 12:41:26.561911570 -0600 +++ linux-2.5-olof/include/asm-ppc64/prom.h 2004-11-16 12:41:26.577915128 -0600 @@ -56,6 +56,8 @@ struct boot_param_header u32 off_mem_rsvmap; /* offset to memory reserve map */ u32 version; /* format version */ u32 last_comp_version; /* last compatible version */ + /* version 2 fields below */ + u32 boot_cpuid_phys; /* Which physical CPU id we're booting on */ }; diff -puN include/asm-ppc64/smp.h~boot-cpuid include/asm-ppc64/smp.h --- linux-2.5/include/asm-ppc64/smp.h~boot-cpuid 2004-11-16 12:41:26.564912237 -0600 +++ linux-2.5-olof/include/asm-ppc64/smp.h 2004-11-16 12:41:26.577915128 -0600 @@ -27,6 +27,7 @@ #include extern int boot_cpuid; +extern int boot_cpuid_phys; extern void cpu_die(void) __attribute__((noreturn)); _ From schwab at suse.de Sun Dec 5 08:24:48 2004 From: schwab at suse.de (Andreas Schwab) Date: Sat, 04 Dec 2004 22:24:48 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> Message-ID: Anton Blanchard writes: >> The 2.6.10-rc3 kernel does not boot on PowerMac G5, the last thing I see >> is "smp_core99_kick_cpu done". Any idea where I should start looking? > > At a guess, does backing out this patch help? It's actually something completely different. The system boots all right, but there is no framebuffer console at all (X is working fine). The problem seems to be the recent pci cleanups. The offb driver wants to reserve 98004000-98183fff, but there is no matching pci resource. 2.6.9: 90000000-9fffffff : /pci at 0,f0000000 90000000-9001ffff : 0000:f0:10.0 91000000-91ffffff : 0000:f0:10.0 98000000-9fffffff : 0000:f0:10.0 98004000-98183fff : offb 2.6.10-rc3: 90000000-9fffffff : /pci at 0,f0000000 90000000-97ffffff : 0000:f0:10.0 98000000-9801ffff : 0000:f0:10.0 Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From benh at kernel.crashing.org Sun Dec 5 15:23:27 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 05 Dec 2004 15:23:27 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> Message-ID: <1102220607.18808.7.camel@gaston> On Sat, 2004-12-04 at 22:24 +0100, Andreas Schwab wrote: > Anton Blanchard writes: > > >> The 2.6.10-rc3 kernel does not boot on PowerMac G5, the last thing I see > >> is "smp_core99_kick_cpu done". Any idea where I should start looking? > > > > At a guess, does backing out this patch help? > > It's actually something completely different. The system boots all right, > but there is no framebuffer console at all (X is working fine). The > problem seems to be the recent pci cleanups. The offb driver wants to > reserve 98004000-98183fff, but there is no matching pci resource. > > 2.6.9: > 90000000-9fffffff : /pci at 0,f0000000 > 90000000-9001ffff : 0000:f0:10.0 > 91000000-91ffffff : 0000:f0:10.0 > 98000000-9fffffff : 0000:f0:10.0 > 98004000-98183fff : offb > > 2.6.10-rc3: > 90000000-9fffffff : /pci at 0,f0000000 > 90000000-97ffffff : 0000:f0:10.0 > 98000000-9801ffff : 0000:f0:10.0 That is very strange ... it looks like the video card is beeing remapped to a different location than where it was initially. Can you send me the dmesg log ? Is this an nvidia or an ATI card ? Does either rivafb or radeonfb work ? Ben. From schwab at suse.de Mon Dec 6 02:56:59 2004 From: schwab at suse.de (Andreas Schwab) Date: Sun, 05 Dec 2004 16:56:59 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: <1102220607.18808.7.camel@gaston> (Benjamin Herrenschmidt's message of "Sun, 05 Dec 2004 15:23:27 +1100") References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102220607.18808.7.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > That is very strange ... it looks like the video card is beeing remapped > to a different location than where it was initially. Can you send me the > dmesg log ? Is this an nvidia or an ATI card ? Does either rivafb or > radeonfb work ? It's an nvidia card, but it is not supported by rivafb (pci id 10de:0321). I have attached /proc/iomem and dmesg output for both 2.6.9 and 2.6.10-rc3. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dmesg-2.6.9 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041205/767be477/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dmesg-2.6.10-rc3 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041205/767be477/attachment-0001.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: iomem-2.6.9 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041205/767be477/attachment-0002.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: iomem-2.6.10-rc3 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041205/767be477/attachment-0003.txt From schwab at suse.de Mon Dec 6 03:36:52 2004 From: schwab at suse.de (Andreas Schwab) Date: Sun, 05 Dec 2004 17:36:52 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: (Andreas Schwab's message of "Sun, 05 Dec 2004 16:56:59 +0100") References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102220607.18808.7.camel@gaston> Message-ID: Andreas Schwab writes: > Benjamin Herrenschmidt writes: > >> That is very strange ... it looks like the video card is beeing remapped >> to a different location than where it was initially. Can you send me the >> dmesg log ? Is this an nvidia or an ATI card ? Does either rivafb or >> radeonfb work ? > > It's an nvidia card, but it is not supported by rivafb (pci id 10de:0321). When I add this id to the list in riva/fbdev.c I get a mangled display, but at least the driver finds the framebuffer memory. 90000000-97ffffff : rivafb f1000000-f1ffffff : rivafb rivafb: nVidia device/chipset 10DE0321 rivafb: Detected CRTC controller 0 being used rivafb: disabling acceleration rivafb: setting virtual Y resolution to 52428 Console: switching to colour frame buffer device 160x64 rivafb: PCI nVidia NV32 framebuffer ver 0.9.5b (64MB @ 0x90000000) Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From tmbinc at elitedvb.net Mon Dec 6 05:29:21 2004 From: tmbinc at elitedvb.net (Felix Domke) Date: Sun, 05 Dec 2004 19:29:21 +0100 Subject: G5 iMac .config Message-ID: <41B35381.3080008@elitedvb.net> I tried to compile a kernel with the iMac-patches posted by J. Mayer, but my kernel doesn't boot. My kernel is 2.6.10-rc2, the patches applied cleanly. The kernel from the gentoo livecd ("imacg5") works well, but i can't find the corresponding .config file anywhere. The last message is "DO-QUIESCE finishedreturning from prom_init". I guess my kernel is just not configured in the right way. Can anybody send me a working .config to work on from or tell me what important things there are to check for? thanks, Felix From benh at kernel.crashing.org Mon Dec 6 07:44:07 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 06 Dec 2004 07:44:07 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102220607.18808.7.camel@gaston> Message-ID: <1102279447.11851.73.camel@gaston> On Sun, 2004-12-05 at 16:56 +0100, Andreas Schwab wrote: > Benjamin Herrenschmidt writes: > > > That is very strange ... it looks like the video card is beeing remapped > > to a different location than where it was initially. Can you send me the > > dmesg log ? Is this an nvidia or an ATI card ? Does either rivafb or > > radeonfb work ? > > It's an nvidia card, but it is not supported by rivafb (pci id 10de:0321). > I have attached /proc/iomem and dmesg output for both 2.6.9 and 2.6.10-rc3. The dmesg doesn't contain anything useful apparently. For some reason, the nVidia card is getting moved around by the PCI code it seems (lspci -vv would probably show you that it gets re-assigned a different location). It's absolutely bad if the kernel starts doing that to cards that are already located to valid addresses. The MacIO (K2) chip itself for example is a PCI device and must _never_ be moved around or the kernel will die right away. It would be useful to enable some PCI debugging to figure out what's going on there. Ben. From tiwari.amit at gmail.com Mon Dec 6 23:59:04 2004 From: tiwari.amit at gmail.com (Amit K Tiwari) Date: Mon, 6 Dec 2004 18:29:04 +0530 Subject: User allocated memory for DMA Message-ID: I am writing a driver for a PCIX board to run on Y-HPC (64-bit Yellow Dog Linux pre-installed on Apple XServe). The application is to process the data acquired from the board and send the results out. The data needs to be acquired by DMA into a user allocated buffer. The amount of data is huge and I need about 1.5 GB per DMA operation. Here is what I am doing: 1. malloc and mlock the memory in user mode. 2. get the user pages (get_user_pages) in the driver. 3. Find out how much physically contiguous memory did the application get (Pass through all the pages and see if the physical addresses got from page_to_phys are contiguous). 4. Prepare a scatter-gather list of contiguous regions. 5. pci_map_sg the sg list to get the DMA addresses for each of the entries. My problem is that at step 3 I do not get any contiguous region. Surprisingly, some of the physical addresses are such that the low order page (say page 151) has high order physical address (say, 1ef234000) while the next high order page (say page 152) has the next lower physical address(say 1ef233000) and this trend continues for some 10 pages after which the addresses totally far apart. As a result of this, my scatter gather list has as many entries as there are pages allocated. Am I doing something bad here? I know there is limit on memory that can be allocated through pci_alloc_*. Is there any other way in which I can allocate memory for DMA? Thanks, Amit K T From grave at ipno.in2p3.fr Tue Dec 7 00:13:42 2004 From: grave at ipno.in2p3.fr (grave) Date: Mon, 06 Dec 2004 13:13:42 +0000 Subject: =?iso-8859-1?q?Re=A0=3A?= User allocated memory for DMA In-Reply-To: (from tiwari.amit@gmail.com on Mon Dec 6 13:59:04 2004) References: Message-ID: <1102338822l.12013l.2l@ipnnarval> Did you check the bigphysmem area in the kernel, as I remember it allow you to reserve a certain amount of memory out of linux... xavier Le 06.12.2004 13:59:04, Amit K Tiwari a ?crit?: > I am writing a driver for a PCIX board to run on Y-HPC (64-bit Yellow > Dog Linux pre-installed on Apple XServe). The application is to > process the data acquired from the board and send the results out. > The > data needs to be acquired by DMA into a user allocated buffer. The > amount of data is huge and I need about 1.5 GB per DMA operation. > > Here is what I am doing: > 1. malloc and mlock the memory in user mode. > 2. get the user pages (get_user_pages) in the driver. > 3. Find out how much physically contiguous memory did the application > get (Pass through all the pages and see if the physical addresses got > from page_to_phys are contiguous). > 4. Prepare a scatter-gather list of contiguous regions. > 5. pci_map_sg the sg list to get the DMA addresses for each of the > entries. > > My problem is that at step 3 I do not get any contiguous region. > Surprisingly, some of the physical addresses are such that the low > order page (say page 151) has high order physical address (say, > 1ef234000) while the next high order page (say page 152) has the next > lower physical address(say 1ef233000) and this trend continues for > some 10 pages after which the addresses totally far apart. > > As a result of this, my scatter gather list has as many entries > as there are pages allocated. > > Am I doing something bad here? > I know there is limit on memory that can be allocated through > pci_alloc_*. Is there any other way in which I can allocate memory > for > DMA? > > Thanks, > Amit K T > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/cgi-bin/mailman/listinfo/linuxppc64-dev > > From jdubois at mc.com Tue Dec 7 00:40:25 2004 From: jdubois at mc.com (Jean-Christophe Dubois) Date: Mon, 06 Dec 2004 14:40:25 +0100 Subject: User allocated memory for DMA In-Reply-To: References: Message-ID: <1102340425.27838.32.camel@fr-jdubois1.ad.mc.com> On Mon, 2004-12-06 at 18:29 +0530, Amit K Tiwari wrote: > I am writing a driver for a PCIX board to run on Y-HPC (64-bit Yellow > Dog Linux pre-installed on Apple XServe). The application is to > process the data acquired from the board and send the results out. The > data needs to be acquired by DMA into a user allocated buffer. The > amount of data is huge and I need about 1.5 GB per DMA operation. > > Here is what I am doing: > 1. malloc and mlock the memory in user mode. Just curious, but is all the G5 memory DMAable? And is your PCIX card DMA engine 64 bits capable? If yes maybe you should consider an approach similar to the bigphysarea patch. This way you could be sure to get one single contiguous block the size you want. As a drawback it may mean that a lot of memory will not be available to Linux but that may be a price you are ready to pay for your application as it will consume this much memory anyway. If required it is trivial to implement some kind of filesystem on top of it to manage this memory region from user space (we have done something like this here even if we didn't need such big chunk of memory). It is a design rather different from the scatter/gather list but it might be more efficient for you overall. > 2. get the user pages (get_user_pages) in the driver. > 3. Find out how much physically contiguous memory did the application > get (Pass through all the pages and see if the physical addresses got > from page_to_phys are contiguous). > 4. Prepare a scatter-gather list of contiguous regions. > 5. pci_map_sg the sg list to get the DMA addresses for each of the entries. > > My problem is that at step 3 I do not get any contiguous region. > Surprisingly, some of the physical addresses are such that the low > order page (say page 151) has high order physical address (say, > 1ef234000) while the next high order page (say page 152) has the next > lower physical address(say 1ef233000) and this trend continues for > some 10 pages after which the addresses totally far apart. > > As a result of this, my scatter gather list has as many entries > as there are pages allocated. > > Am I doing something bad here? > I know there is limit on memory that can be allocated through > pci_alloc_*. Is there any other way in which I can allocate memory for > DMA? > > Thanks, > Amit K T > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/cgi-bin/mailman/listinfo/linuxppc64-dev From olof at austin.ibm.com Tue Dec 7 01:21:59 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Mon, 06 Dec 2004 08:21:59 -0600 Subject: User allocated memory for DMA In-Reply-To: References: Message-ID: <41B46B07.4060504@austin.ibm.com> Amit K Tiwari wrote: >I am writing a driver for a PCIX board to run on Y-HPC (64-bit Yellow >Dog Linux pre-installed on Apple XServe). The application is to >process the data acquired from the board and send the results out. The >data needs to be acquired by DMA into a user allocated buffer. The >amount of data is huge and I need about 1.5 GB per DMA operation. > > The current IOMMU isn't quite written with the expectation that the user will keep a 1.5GB mapping of DMA memory active for an extensive period of time. It should work, but let me know if you see any strangeness. >Here is what I am doing: >1. malloc and mlock the memory in user mode. >2. get the user pages (get_user_pages) in the driver. >3. Find out how much physically contiguous memory did the application >get (Pass through all the pages and see if the physical addresses got >from page_to_phys are contiguous). >4. Prepare a scatter-gather list of contiguous regions. >5. pci_map_sg the sg list to get the DMA addresses for each of the entries. > >My problem is that at step 3 I do not get any contiguous region. >Surprisingly, some of the physical addresses are such that the low >order page (say page 151) has high order physical address (say, >1ef234000) while the next high order page (say page 152) has the next >lower physical address(say 1ef233000) and this trend continues for >some 10 pages after which the addresses totally far apart. > > This doesn't really surprise me. You have no guarantees where in physical memory that a process will get its pages allocated, they can be anywhere. The nice thing is that with the IOMMU, you can get a mostly contigous address range as seen by the PCI adapter. The translation between the two is transparent to the DMA operation. >As a result of this, my scatter gather list has as many entries >as there are pages allocated. > >Am I doing something bad here? >I know there is limit on memory that can be allocated through >pci_alloc_*. Is there any other way in which I can allocate memory for >DMA? > > Have you considered making your application use large pages? If so, you'd at least get 16MB contigous at a time. -Olof From olof at austin.ibm.com Tue Dec 7 01:25:46 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Mon, 06 Dec 2004 08:25:46 -0600 Subject: User allocated memory for DMA In-Reply-To: <1102340425.27838.32.camel@fr-jdubois1.ad.mc.com> References: <1102340425.27838.32.camel@fr-jdubois1.ad.mc.com> Message-ID: <41B46BEA.5080805@austin.ibm.com> Jean-Christophe Dubois wrote: >Just curious, but is all the G5 memory DMAable? And is your PCIX card >DMA engine 64 bits capable? > All memory on the G5 can be used for DMA, but only via the IOMMU. For G5s with less than 2GB of memory, the IOMMU is per default disabled since it's not needed. There's no hardware support for 64-bit DMA on G5s, so it unfortunately doesn't matter what the card supports. -Olof From will_schmidt at vnet.ibm.com Tue Dec 7 04:16:25 2004 From: will_schmidt at vnet.ibm.com (will schmidt) Date: Mon, 06 Dec 2004 11:16:25 -0600 Subject: [PPC64] Patch to correct alignment for lppaca in paca_struct Message-ID: <41B493E9.7060004@vnet.ibm.com> Hi, We found that we were failing register_vpa calls in cases where the lppaca structure (part of the PACA) crosses a page boundary. (LTC bug 12689). This was causing us (lparcfg specifically) some grief as the xSharedProc bit was not being set. The attached patch changes the alignment of the lppaca structure, and a few comments so we understand why. -Will Signed-off-by: Will Schmidt --- a/include/asm-ppc64/paca.h 2004-12-03 13:03:09.048520608 -0600 +++ b/include/asm-ppc64/paca.h 2004-12-03 13:18:17.433655752 -0600 @@ -99,11 +99,13 @@ u64 exdsi[8]; /* used for linear mapping hash table misses */ /* - * iSeries structues which the hypervisor knows about - Not - * sure if these particularly need to be cacheline aligned. + * iSeries structues which the hypervisor knows about - + * This structure should not cross a page boundary. + * The vpa_init/register_vpa call is now known to fail if the lppaca + * structure crosses a page boundary. * The lppaca is also used on POWER5 pSeries boxes. */ - struct ItLpPaca lppaca __attribute__((aligned(0x80))); + struct ItLpPaca lppaca __attribute__((aligned(0x400))); #ifdef CONFIG_PPC_ISERIES struct ItLpRegSave reg_save; #endif From haveblue at us.ibm.com Tue Dec 7 05:28:06 2004 From: haveblue at us.ibm.com (Dave Hansen) Date: Mon, 06 Dec 2004 10:28:06 -0800 Subject: [PPC64] Patch to correct alignment for lppaca in paca_struct In-Reply-To: <41B493E9.7060004@vnet.ibm.com> References: <41B493E9.7060004@vnet.ibm.com> Message-ID: <1102357686.5656.39.camel@localhost> On Mon, 2004-12-06 at 09:16, will schmidt wrote: > - struct ItLpPaca lppaca __attribute__((aligned(0x80))); > + struct ItLpPaca lppaca __attribute__((aligned(0x400))); Do you have guarantees about how large the lppaca can get? If it's larger than 0x400 bytes, you can still cross a page boundary, right? Maybe you should just align it to PAGE_SIZE and be done with it. -- Dave From david at gibson.dropbear.id.au Tue Dec 7 11:27:06 2004 From: david at gibson.dropbear.id.au (David Gibson) Date: Tue, 7 Dec 2004 11:27:06 +1100 Subject: [PPC64] Patch to correct alignment for lppaca in paca_struct In-Reply-To: <1102357686.5656.39.camel@localhost> References: <41B493E9.7060004@vnet.ibm.com> <1102357686.5656.39.camel@localhost> Message-ID: <20041207002706.GB9205@zax> On Mon, Dec 06, 2004 at 10:28:06AM -0800, Dave Hansen wrote: > On Mon, 2004-12-06 at 09:16, will schmidt wrote: > > - struct ItLpPaca lppaca __attribute__((aligned(0x80))); > > + struct ItLpPaca lppaca __attribute__((aligned(0x400))); > > Do you have guarantees about how large the lppaca can get? If it's > larger than 0x400 bytes, you can still cross a page boundary, right? > Maybe you should just align it to PAGE_SIZE and be done with it. The lppaca is part of the firmware ABI, so it can't just go randomly changing or growing. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist. NOT _the_ _other_ _way_ | _around_! http://www.ozlabs.org/people/dgibson From benh at kernel.crashing.org Tue Dec 7 18:09:48 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Tue, 07 Dec 2004 18:09:48 +1100 Subject: User allocated memory for DMA In-Reply-To: References: Message-ID: <1102403388.11502.8.camel@gaston> On Mon, 2004-12-06 at 18:29 +0530, Amit K Tiwari wrote: > My problem is that at step 3 I do not get any contiguous region. > Surprisingly, some of the physical addresses are such that the low > order page (say page 151) has high order physical address (say, > 1ef234000) while the next high order page (say page 152) has the next > lower physical address(say 1ef233000) and this trend continues for > some 10 pages after which the addresses totally far apart. What kernel version is this ? I remember something about the default allocation "direction" of pages beeing changed a while ago... Ben. From schwab at suse.de Wed Dec 8 11:49:11 2004 From: schwab at suse.de (Andreas Schwab) Date: Wed, 08 Dec 2004 01:49:11 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: <1102464972.11516.46.camel@gaston> (Benjamin Herrenschmidt's message of "Wed, 08 Dec 2004 11:16:12 +1100") References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> <1102464972.11516.46.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > pci_probe_only should be set to 0 by the pmac_pci.c code, thus causing > pci_assign_unassigned_resources() to actually be called... Not really. arch/ppc64/kernel/pci.c: unsigned long pci_probe_only = 1; arch/ppc64/kernel/pmac_pci.c: extern int pci_probe_only; This has been fixed in rc3 .... > - pci_assign_unassigned_resources() seem to not work properly, that is, > it moves around things that don't need to be moved thus causing your > problem when it's actually called. Probably has always been broken. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From benh at kernel.crashing.org Wed Dec 8 10:47:46 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Dec 2004 10:47:46 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> Message-ID: <1102463266.11516.39.camel@gaston> On Wed, 2004-12-08 at 00:26 +0100, Andreas Schwab wrote: > Benjamin Herrenschmidt writes: > > > Have you found out what causes the kernel PCI layer to re-allocate the > > video card resources ? I should definitely not do that ... > > Sorry, but I have no idea about all that stuff. Please advice! > > > Can you send me the lspci -vv (as root) output with both kernels ? > > Attached. > > > Also compile the PCI layer with DEBUG enabled ... > > I've enabled DEBUG in all files in drivers/pci and in > arch/ppc64/kernel/pci.c. If you need more please tell. I don't understand ... the 2 lspci's were taken with the same machine ? The PCI setup is totally different ... pretty much everything got moved around ! That is really bad. You don't seem to have debug enabled in drivers/pci/setup-bus.c tho, can you check if pci_assign_unassigned_resources() is called at all in either kernel ? Ben. From schwab at suse.de Wed Dec 8 11:07:01 2004 From: schwab at suse.de (Andreas Schwab) Date: Wed, 08 Dec 2004 01:07:01 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: <1102463266.11516.39.camel@gaston> (Benjamin Herrenschmidt's message of "Wed, 08 Dec 2004 10:47:46 +1100") References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > I don't understand ... the 2 lspci's were taken with the same machine ? Sure. :-) > You don't seem to have debug enabled in drivers/pci/setup-bus.c tho, I have, it's the default. > can you check if pci_assign_unassigned_resources() is called at all in > either kernel ? It appears to be called in 2.6.10-rc3, but not in 2.6.9. PCI: Probing PCI hardware PCI: Bus 1, bridge: 0001:00:01.0 IO window: disabled. MEM window: 80000000-800fffff PREFETCH window: disabled. PCI: Bus 5, bridge: 0001:00:02.0 IO window: disabled. MEM window: 80100000-801fffff PREFETCH window: disabled. PCI: Bus 2, bridge: 0001:00:03.0 IO window: disabled. MEM window: 80200000-802fffff PREFETCH window: disabled. PCI: Bus 3, bridge: 0001:00:04.0 IO window: disabled. MEM window: 80300000-805fffff PREFETCH window: disabled. PCI: Bus 4, bridge: 0001:00:05.0 IO window: disabled. MEM window: 80600000-806fffff PREFETCH window: disabled. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From benh at kernel.crashing.org Wed Dec 8 09:00:36 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Dec 2004 09:00:36 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> Message-ID: <1102456836.11502.33.camel@gaston> On Sat, 2004-12-04 at 22:24 +0100, Andreas Schwab wrote: > $ce. > > 2.6.9: > 90000000-9fffffff : /pci at 0,f0000000 > 90000000-9001ffff : 0000:f0:10.0 > 91000000-91ffffff : 0000:f0:10.0 > 98000000-9fffffff : 0000:f0:10.0 > 98004000-98183fff : offb > > 2.6.10-rc3: > 90000000-9fffffff : /pci at 0,f0000000 > 90000000-97ffffff : 0000:f0:10.0 > 98000000-9801ffff : 0000:f0:10.0 Have you found out what causes the kernel PCI layer to re-allocate the video card resources ? I should definitely not do that ... Can you send me the lspci -vv (as root) output with both kernels ? Also compile the PCI layer with DEBUG enabled ... Ben. From benh at kernel.crashing.org Wed Dec 8 11:54:43 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Dec 2004 11:54:43 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> <1102464972.11516.46.camel@gaston> Message-ID: <1102467283.11502.49.camel@gaston> On Wed, 2004-12-08 at 01:49 +0100, Andreas Schwab wrote: > Benjamin Herrenschmidt writes: > > > pci_probe_only should be set to 0 by the pmac_pci.c code, thus causing > > pci_assign_unassigned_resources() to actually be called... > > Not really. > > arch/ppc64/kernel/pci.c: > unsigned long pci_probe_only = 1; > > arch/ppc64/kernel/pmac_pci.c: > extern int pci_probe_only; In my 2.6.9 snapshot here, in pmac_pci.c : /* Tell pci.c to use the common resource allocation mecanism */ pci_probe_only = 0; > This has been fixed in rc3 .... Hrm... what -rc3 ? > > - pci_assign_unassigned_resources() seem to not work properly, that is, > > it moves around things that don't need to be moved thus causing your > > problem when it's actually called. > > Probably has always been broken. Yes, but still needs to be fixed :) Ben. From benh at kernel.crashing.org Wed Dec 8 11:16:12 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Dec 2004 11:16:12 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> Message-ID: <1102464972.11516.46.camel@gaston> On Wed, 2004-12-08 at 01:07 +0100, Andreas Schwab wrote: > Benjamin Herrenschmidt writes: > > > I don't understand ... the 2 lspci's were taken with the same machine ? > > Sure. :-) > > > You don't seem to have debug enabled in drivers/pci/setup-bus.c tho, > > I have, it's the default. > > > can you check if pci_assign_unassigned_resources() is called at all in > > either kernel ? > > It appears to be called in 2.6.10-rc3, but not in 2.6.9. I have no explanation for why it's not called in 2.6.9 ... Can you have a look at what's going on in 2.6.9 arch/ppc64/kernel/pci.c ? pci_probe_only should be set to 0 by the pmac_pci.c code, thus causing pci_assign_unassigned_resources() to actually be called... There are 2 different issues here: - pci_assign_unassigned_resources() should be called by both kernels, I want to understand why it's not by 2.6.9... - pci_assign_unassigned_resources() seem to not work properly, that is, it moves around things that don't need to be moved thus causing your problem when it's actually called. The later, I'll do a workaround by leaving pci_probe_only to 1 instead of 0 for 2.6.10, but we need to get that fixed in the long term... Ben. From schwab at suse.de Wed Dec 8 10:26:19 2004 From: schwab at suse.de (Andreas Schwab) Date: Wed, 08 Dec 2004 00:26:19 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > Have you found out what causes the kernel PCI layer to re-allocate the > video card resources ? I should definitely not do that ... Sorry, but I have no idea about all that stuff. Please advice! > Can you send me the lspci -vv (as root) output with both kernels ? Attached. > Also compile the PCI layer with DEBUG enabled ... I've enabled DEBUG in all files in drivers/pci and in arch/ppc64/kernel/pci.c. If you need more please tell. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lspci-2.6.9 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041208/8ef8a47d/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: lspci-2.6.10-rc3 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041208/8ef8a47d/attachment-0001.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pci-debug Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041208/8ef8a47d/attachment-0002.txt From schwab at suse.de Wed Dec 8 12:04:03 2004 From: schwab at suse.de (Andreas Schwab) Date: Wed, 08 Dec 2004 02:04:03 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: <1102467283.11502.49.camel@gaston> (Benjamin Herrenschmidt's message of "Wed, 08 Dec 2004 11:54:43 +1100") References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> <1102464972.11516.46.camel@gaston> <1102467283.11502.49.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > On Wed, 2004-12-08 at 01:49 +0100, Andreas Schwab wrote: >> Benjamin Herrenschmidt writes: >> >> > pci_probe_only should be set to 0 by the pmac_pci.c code, thus causing >> > pci_assign_unassigned_resources() to actually be called... >> >> Not really. >> >> arch/ppc64/kernel/pci.c: >> unsigned long pci_probe_only = 1; >> >> arch/ppc64/kernel/pmac_pci.c: >> extern int pci_probe_only; > > In my 2.6.9 snapshot here, in pmac_pci.c : > > /* Tell pci.c to use the common resource allocation mecanism */ > pci_probe_only = 0; Which is a no-op in 2.6.9. Remember, we are 64 bit. >> This has been fixed in rc3 .... > > Hrm... what -rc3 ? See the subject. Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From benh at kernel.crashing.org Wed Dec 8 12:40:24 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Dec 2004 12:40:24 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> <1102464972.11516.46.camel@gaston> <1102467283.11502.49.camel@gaston> Message-ID: <1102470024.11516.54.camel@gaston> On Wed, 2004-12-08 at 02:04 +0100, Andreas Schwab wrote: > > > > In my 2.6.9 snapshot here, in pmac_pci.c : > > > > /* Tell pci.c to use the common resource allocation mecanism */ > > pci_probe_only = 0; > > Which is a no-op in 2.6.9. Remember, we are 64 bit. #ifndef CONFIG_PPC_ISERIES if (pci_probe_only) pcibios_claim_of_setup(); else /* FIXME: `else' will be removed when pci_assign_unassigned_resources() is able to work correctly with [partially] allocated PCI tree. */ pci_assign_unassigned_resources(); #endif /* !CONFIG_PPC_ISERIES */ (in pcibios_init() in 2.6.9) Doesn't look like a no-op :) Ben. From anton at samba.org Wed Dec 8 13:02:22 2004 From: anton at samba.org (Anton Blanchard) Date: Wed, 8 Dec 2004 13:02:22 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: <1102470024.11516.54.camel@gaston> References: <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> <1102464972.11516.46.camel@gaston> <1102467283.11502.49.camel@gaston> <1102470024.11516.54.camel@gaston> Message-ID: <20041208020222.GB31411@krispykreme.ozlabs.ibm.com> > Doesn't look like a no-op :) Look closer, accessing something as an int when its a long :) Anton From benh at kernel.crashing.org Wed Dec 8 13:03:28 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Dec 2004 13:03:28 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: <20041208020222.GB31411@krispykreme.ozlabs.ibm.com> References: <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> <1102464972.11516.46.camel@gaston> <1102467283.11502.49.camel@gaston> <1102470024.11516.54.camel@gaston> <20041208020222.GB31411@krispykreme.ozlabs.ibm.com> Message-ID: <1102471408.11517.56.camel@gaston> On Wed, 2004-12-08 at 13:02 +1100, Anton Blanchard wrote: > > Doesn't look like a no-op :) > > Look closer, accessing something as an int when its a long :) Ahaha :) Ok, I'll fix pmac for now. Ben. From benh at kernel.crashing.org Wed Dec 8 13:05:15 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Dec 2004 13:05:15 +1100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> <1102464972.11516.46.camel@gaston> Message-ID: <1102471515.25180.58.camel@gaston> Ok, let me know if that works: Index: linux-work/arch/ppc64/kernel/pmac_pci.c =================================================================== --- linux-work.orig/arch/ppc64/kernel/pmac_pci.c 2004-11-22 11:49:24.000000000 +1100 +++ linux-work/arch/ppc64/kernel/pmac_pci.c 2004-12-08 13:04:42.607006832 +1100 @@ -739,8 +739,8 @@ pmac_check_ht_link(); - /* Tell pci.c to use the common resource allocation mecanism */ - pci_probe_only = 0; + /* Tell pci.c to not use the common resource allocation mecanism */ + pci_probe_only = 1; /* Allow all IO */ io_page_mask = -1; From tiwari.amit at gmail.com Wed Dec 8 14:42:04 2004 From: tiwari.amit at gmail.com (Amit K Tiwari) Date: Wed, 8 Dec 2004 09:12:04 +0530 Subject: User allocated memory for DMA In-Reply-To: <1102403388.11502.8.camel@gaston> References: <1102403388.11502.8.camel@gaston> Message-ID: This is 2.6.6 (64 bit Yellow Dog Linux from Terrasoft for Apple XServe) Amit K T On Tue, 07 Dec 2004 18:09:48 +1100, Benjamin Herrenschmidt wrote: > On Mon, 2004-12-06 at 18:29 +0530, Amit K Tiwari wrote: > > > My problem is that at step 3 I do not get any contiguous region. > > Surprisingly, some of the physical addresses are such that the low > > order page (say page 151) has high order physical address (say, > > 1ef234000) while the next high order page (say page 152) has the next > > lower physical address(say 1ef233000) and this trend continues for > > some 10 pages after which the addresses totally far apart. > > What kernel version is this ? I remember something about the default > allocation "direction" of pages beeing changed a while ago... > > Ben. > > From tiwari.amit at gmail.com Wed Dec 8 14:49:01 2004 From: tiwari.amit at gmail.com (Amit K Tiwari) Date: Wed, 8 Dec 2004 09:19:01 +0530 Subject: User allocated memory for DMA In-Reply-To: <41B46B07.4060504@austin.ibm.com> References: <41B46B07.4060504@austin.ibm.com> Message-ID: Thanks, it helped a lot. Here is what works - 1. Increase the shared memory limit (sysctl kernel.shmmax) 2. Configure the large pages (echo 256 > /proc/sys/vm/nr_hugepages) 3. Use shmget to get a handle to huge pages - Set the SHM_HUGETLB bits in flags. On Mon, 06 Dec 2004 08:21:59 -0600, Olof Johansson wrote: > Amit K Tiwari wrote: > > >I am writing a driver for a PCIX board to run on Y-HPC (64-bit Yellow > >Dog Linux pre-installed on Apple XServe). The application is to > >process the data acquired from the board and send the results out. The > >data needs to be acquired by DMA into a user allocated buffer. The > >amount of data is huge and I need about 1.5 GB per DMA operation. > > > > > The current IOMMU isn't quite written with the expectation that the user > will keep a 1.5GB mapping of DMA memory active for an extensive period > of time. It should work, but let me know if you see any strangeness. > > > > >Here is what I am doing: > >1. malloc and mlock the memory in user mode. > >2. get the user pages (get_user_pages) in the driver. > >3. Find out how much physically contiguous memory did the application > >get (Pass through all the pages and see if the physical addresses got > >from page_to_phys are contiguous). > >4. Prepare a scatter-gather list of contiguous regions. > >5. pci_map_sg the sg list to get the DMA addresses for each of the entries. > > > >My problem is that at step 3 I do not get any contiguous region. > >Surprisingly, some of the physical addresses are such that the low > >order page (say page 151) has high order physical address (say, > >1ef234000) while the next high order page (say page 152) has the next > >lower physical address(say 1ef233000) and this trend continues for > >some 10 pages after which the addresses totally far apart. > > > > > This doesn't really surprise me. You have no guarantees where in > physical memory that a process will get its pages allocated, they can be > anywhere. The nice thing is that with the IOMMU, you can get a mostly > contigous address range as seen by the PCI adapter. The translation > between the two is transparent to the DMA operation. > > >As a result of this, my scatter gather list has as many entries > >as there are pages allocated. > > > >Am I doing something bad here? > >I know there is limit on memory that can be allocated through > >pci_alloc_*. Is there any other way in which I can allocate memory for > >DMA? > > > > > Have you considered making your application use large pages? If so, > you'd at least get 16MB contigous at a time. > > > -Olof > From benh at kernel.crashing.org Wed Dec 8 15:45:17 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Wed, 08 Dec 2004 15:45:17 +1100 Subject: User allocated memory for DMA In-Reply-To: References: <41B46B07.4060504@austin.ibm.com> Message-ID: <1102481117.11503.62.camel@gaston> On Wed, 2004-12-08 at 09:19 +0530, Amit K Tiwari wrote: > Thanks, it helped a lot. > Here is what works - > 1. Increase the shared memory limit (sysctl kernel.shmmax) > 2. Configure the large pages (echo 256 > /proc/sys/vm/nr_hugepages) > 3. Use shmget to get a handle to huge pages - Set the SHM_HUGETLB > bits in flags. Still, user pages beeing mapped in wrong order is a bit worrying... I may be fixed in more recent kernels, or not, I'd rather do some investigation... Ben. From schwab at suse.de Wed Dec 8 21:21:04 2004 From: schwab at suse.de (Andreas Schwab) Date: Wed, 08 Dec 2004 11:21:04 +0100 Subject: 2.6.10-rc3 does not boot on PowerMac In-Reply-To: <1102471515.25180.58.camel@gaston> (Benjamin Herrenschmidt's message of "Wed, 08 Dec 2004 13:05:15 +1100") References: <20041204182043.GG7714@krispykreme.ozlabs.ibm.com> <1102456836.11502.33.camel@gaston> <1102463266.11516.39.camel@gaston> <1102464972.11516.46.camel@gaston> <1102471515.25180.58.camel@gaston> Message-ID: Benjamin Herrenschmidt writes: > Ok, let me know if that works: > > Index: linux-work/arch/ppc64/kernel/pmac_pci.c > =================================================================== > --- linux-work.orig/arch/ppc64/kernel/pmac_pci.c 2004-11-22 11:49:24.000000000 +1100 > +++ linux-work/arch/ppc64/kernel/pmac_pci.c 2004-12-08 13:04:42.607006832 +1100 > @@ -739,8 +739,8 @@ > > pmac_check_ht_link(); > > - /* Tell pci.c to use the common resource allocation mecanism */ > - pci_probe_only = 0; > + /* Tell pci.c to not use the common resource allocation mecanism */ > + pci_probe_only = 1; > > /* Allow all IO */ > io_page_mask = -1; Yes, that works (just as well as commenting it out since it's default anyway). Andreas. -- Andreas Schwab, SuSE Labs, schwab at suse.de SuSE Linux Products GmbH, Maxfeldstra?e 5, 90409 N?rnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From ebenoit at hopevale.com Thu Dec 9 02:02:57 2004 From: ebenoit at hopevale.com (Eric) Date: Wed, 08 Dec 2004 10:02:57 -0500 Subject: unsubscribe Message-ID: <41B717A1.50901@hopevale.com> From sfr at canb.auug.org.au Thu Dec 9 00:38:00 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 9 Dec 2004 00:38:00 +1100 Subject: naca cleanups Message-ID: <20041209003800.7e38a32c.sfr@canb.auug.org.au> Hi all, I have been "encouraged" to clean up the naca and as a first pass, I have been looking at moving some of the fields out of the naca. Of course, my understanding of the naca is "incomplete" so first question: Does anyone know if the [di]CacheL1LogLineSize and [di]LinesPerPage fields need to be in the naca and would there be any problem in moving them to the systemcfg structure? -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041209/04ad8af9/attachment.pgp From anton at samba.org Thu Dec 9 01:08:59 2004 From: anton at samba.org (Anton Blanchard) Date: Thu, 9 Dec 2004 01:08:59 +1100 Subject: naca cleanups In-Reply-To: <20041209003800.7e38a32c.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> Message-ID: <20041208140859.GB32138@krispykreme.ozlabs.ibm.com> Hi Stephen, > I have been "encouraged" to clean up the naca and as a first pass, I > have been looking at moving some of the fields out of the naca. Of course, > my understanding of the naca is "incomplete" so first question: > > Does anyone know if the [di]CacheL1LogLineSize and [di]LinesPerPage fields > need to be in the naca and would there be any problem in moving them to > the systemcfg structure? I cant see why they need to be in there. I always wondered if we would be able to handle a change in cacheline size, if the *CacheL1* stuff doesnt cover it all then we may as well use #defines instead. I _think_ only the first 4 fields in the NACA are architected by the OS/400 hypervisor, and none of them by phyp. Anton From sfr at canb.auug.org.au Thu Dec 9 01:28:27 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 9 Dec 2004 01:28:27 +1100 Subject: naca cleanups In-Reply-To: <20041208140859.GB32138@krispykreme.ozlabs.ibm.com> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041208140859.GB32138@krispykreme.ozlabs.ibm.com> Message-ID: <20041209012827.2f5be3a4.sfr@canb.auug.org.au> On Thu, 9 Dec 2004 01:08:59 +1100 Anton Blanchard wrote: > > > I have been "encouraged" to clean up the naca and as a first pass, I > > have been looking at moving some of the fields out of the naca. Of course, > > my understanding of the naca is "incomplete" so first question: > > > > Does anyone know if the [di]CacheL1LogLineSize and [di]LinesPerPage fields > > need to be in the naca and would there be any problem in moving them to > > the systemcfg structure? > > I cant see why they need to be in there. I always wondered if we would > be able to handle a change in cacheline size, if the *CacheL1* stuff > doesnt cover it all then we may as well use #defines instead. > > I _think_ only the first 4 fields in the NACA are architected by the > OS/400 hypervisor, and none of them by phyp. OK, so how about this as a first pass. I have left the fields in the naca just in case something reads them out of /proc/ppc64/naca. Untested, not even compiled, just for comment (especially the asm bits). -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk/arch/ppc64/kernel/asm-offsets.c linus-bk-naca.1/arch/ppc64/kernel/asm-offsets.c --- linus-bk/arch/ppc64/kernel/asm-offsets.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.1/arch/ppc64/kernel/asm-offsets.c 2004-12-09 00:59:10.000000000 +1100 @@ -70,11 +70,11 @@ /* naca */ DEFINE(PACA, offsetof(struct naca_struct, paca)); DEFINE(DCACHEL1LINESIZE, offsetof(struct systemcfg, dCacheL1LineSize)); - DEFINE(DCACHEL1LOGLINESIZE, offsetof(struct naca_struct, dCacheL1LogLineSize)); - DEFINE(DCACHEL1LINESPERPAGE, offsetof(struct naca_struct, dCacheL1LinesPerPage)); + DEFINE(DCACHEL1LOGLINESIZE, offsetof(struct systemcfg, dCacheL1LogLineSize)); + DEFINE(DCACHEL1LINESPERPAGE, offsetof(struct systemcfg, dCacheL1LinesPerPage)); DEFINE(ICACHEL1LINESIZE, offsetof(struct systemcfg, iCacheL1LineSize)); - DEFINE(ICACHEL1LOGLINESIZE, offsetof(struct naca_struct, iCacheL1LogLineSize)); - DEFINE(ICACHEL1LINESPERPAGE, offsetof(struct naca_struct, iCacheL1LinesPerPage)); + DEFINE(ICACHEL1LOGLINESIZE, offsetof(struct systemcfg, iCacheL1LogLineSize)); + DEFINE(ICACHEL1LINESPERPAGE, offsetof(struct systemcfg, iCacheL1LinesPerPage)); DEFINE(PLATFORM, offsetof(struct systemcfg, platform)); /* paca */ diff -ruN linus-bk/arch/ppc64/kernel/iSeries_setup.c linus-bk-naca.1/arch/ppc64/kernel/iSeries_setup.c --- linus-bk/arch/ppc64/kernel/iSeries_setup.c 2004-11-12 09:09:48.000000000 +1100 +++ linus-bk-naca.1/arch/ppc64/kernel/iSeries_setup.c 2004-12-09 01:01:44.000000000 +1100 @@ -568,20 +568,26 @@ xIoHriProcessorVpd[procIx].xDataL1CacheSizeKB * 1024; systemcfg->dCacheL1LineSize = xIoHriProcessorVpd[procIx].xDataCacheOperandSize; - naca->iCacheL1LinesPerPage = PAGE_SIZE / systemcfg->iCacheL1LineSize; - naca->dCacheL1LinesPerPage = PAGE_SIZE / systemcfg->dCacheL1LineSize; + systemcfg->iCacheL1LinesPerPage = + naca->iCacheL1LinesPerPage = + PAGE_SIZE / systemcfg->iCacheL1LineSize; + systemcfg->dCacheL1LinesPerPage = + naca->dCacheL1LinesPerPage = + PAGE_SIZE / systemcfg->dCacheL1LineSize; i = systemcfg->iCacheL1LineSize; n = 0; while ((i = (i / 2))) ++n; - naca->iCacheL1LogLineSize = n; + systemcfg->iCacheL1LogLineSize = + naca->iCacheL1LogLineSize = n; i = systemcfg->dCacheL1LineSize; n = 0; while ((i = (i / 2))) ++n; - naca->dCacheL1LogLineSize = n; + systemcfg->dCacheL1LogLineSize = + naca->dCacheL1LogLineSize = n; printk("D-cache line size = %d\n", (unsigned int)systemcfg->dCacheL1LineSize); diff -ruN linus-bk/arch/ppc64/kernel/misc.S linus-bk-naca.1/arch/ppc64/kernel/misc.S --- linus-bk/arch/ppc64/kernel/misc.S 2004-11-12 09:09:48.000000000 +1100 +++ linus-bk-naca.1/arch/ppc64/kernel/misc.S 2004-12-09 00:51:37.000000000 +1100 @@ -207,8 +207,6 @@ * and in some cases i-cache and d-cache line sizes differ from * each other. */ - LOADADDR(r10,naca) /* Get Naca address */ - ld r10,0(r10) LOADADDR(r11,systemcfg) /* Get systemcfg address */ ld r11,0(r11) lwz r7,DCACHEL1LINESIZE(r11)/* Get cache line size */ @@ -216,7 +214,7 @@ andc r6,r3,r5 /* round low to line bdy */ subf r8,r6,r4 /* compute length */ add r8,r8,r5 /* ensure we get enough */ - lwz r9,DCACHEL1LOGLINESIZE(r10) /* Get log-2 of cache line size */ + lwz r9,DCACHEL1LOGLINESIZE(r11) /* Get log-2 of cache line size */ srw. r8,r8,r9 /* compute line count */ beqlr /* nothing to do? */ mtctr r8 @@ -232,7 +230,7 @@ andc r6,r3,r5 /* round low to line bdy */ subf r8,r6,r4 /* compute length */ add r8,r8,r5 - lwz r9,ICACHEL1LOGLINESIZE(r10) /* Get log-2 of Icache line size */ + lwz r9,ICACHEL1LOGLINESIZE(r11) /* Get log-2 of Icache line size */ srw. r8,r8,r9 /* compute line count */ beqlr /* nothing to do? */ mtctr r8 @@ -256,8 +254,6 @@ * * Different systems have different cache line sizes */ - LOADADDR(r10,naca) /* Get Naca address */ - ld r10,0(r10) LOADADDR(r11,systemcfg) /* Get systemcfg address */ ld r11,0(r11) lwz r7,DCACHEL1LINESIZE(r11) /* Get dcache line size */ @@ -265,7 +261,7 @@ andc r6,r3,r5 /* round low to line bdy */ subf r8,r6,r4 /* compute length */ add r8,r8,r5 /* ensure we get enough */ - lwz r9,DCACHEL1LOGLINESIZE(r10) /* Get log-2 of dcache line size */ + lwz r9,DCACHEL1LOGLINESIZE(r11) /* Get log-2 of dcache line size */ srw. r8,r8,r9 /* compute line count */ beqlr /* nothing to do? */ mtctr r8 @@ -286,8 +282,6 @@ * flush all bytes from start to stop-1 inclusive */ _GLOBAL(flush_dcache_phys_range) - LOADADDR(r10,naca) /* Get Naca address */ - ld r10,0(r10) LOADADDR(r11,systemcfg) /* Get systemcfg address */ ld r11,0(r11) lwz r7,DCACHEL1LINESIZE(r11) /* Get dcache line size */ @@ -295,7 +289,7 @@ andc r6,r3,r5 /* round low to line bdy */ subf r8,r6,r4 /* compute length */ add r8,r8,r5 /* ensure we get enough */ - lwz r9,DCACHEL1LOGLINESIZE(r10) /* Get log-2 of dcache line size */ + lwz r9,DCACHEL1LOGLINESIZE(r11) /* Get log-2 of dcache line size */ srw. r8,r8,r9 /* compute line count */ beqlr /* nothing to do? */ mfmsr r5 /* Disable MMU Data Relocation */ @@ -332,12 +326,10 @@ */ /* Flush the dcache */ - LOADADDR(r7,naca) - ld r7,0(r7) LOADADDR(r8,systemcfg) /* Get systemcfg address */ ld r8,0(r8) clrrdi r3,r3,12 /* Page align */ - lwz r4,DCACHEL1LINESPERPAGE(r7) /* Get # dcache lines per page */ + lwz r4,DCACHEL1LINESPERPAGE(r8) /* Get # dcache lines per page */ lwz r5,DCACHEL1LINESIZE(r8) /* Get dcache line size */ mr r6,r3 mtctr r4 @@ -348,7 +340,7 @@ /* Now invalidate the icache */ - lwz r4,ICACHEL1LINESPERPAGE(r7) /* Get # icache lines per page */ + lwz r4,ICACHEL1LINESPERPAGE(r8) /* Get # icache lines per page */ lwz r5,ICACHEL1LINESIZE(r8) /* Get icache line size */ mtctr r4 1: icbi 0,r3 diff -ruN linus-bk/arch/ppc64/kernel/setup.c linus-bk-naca.1/arch/ppc64/kernel/setup.c --- linus-bk/arch/ppc64/kernel/setup.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.1/arch/ppc64/kernel/setup.c 2004-12-09 00:57:58.000000000 +1100 @@ -496,8 +496,10 @@ systemcfg->dCacheL1Size = size; systemcfg->dCacheL1LineSize = lsize; - naca->dCacheL1LogLineSize = __ilog2(lsize); - naca->dCacheL1LinesPerPage = PAGE_SIZE/(lsize); + systemcfg->dCacheL1LogLineSize = + naca->dCacheL1LogLineSize = __ilog2(lsize); + systemcfg->dCacheL1LinesPerPage = + naca->dCacheL1LinesPerPage = PAGE_SIZE/(lsize); size = 0; lsize = cur_cpu_spec->icache_bsize; @@ -513,8 +515,10 @@ systemcfg->iCacheL1Size = size; systemcfg->iCacheL1LineSize = lsize; - naca->iCacheL1LogLineSize = __ilog2(lsize); - naca->iCacheL1LinesPerPage = PAGE_SIZE/(lsize); + systemcfg->iCacheL1LogLineSize + naca->iCacheL1LogLineSize = __ilog2(lsize); + systemcfg->iCacheL1LinesPerPage + naca->iCacheL1LinesPerPage = PAGE_SIZE/(lsize); } } diff -ruN linus-bk/include/asm-ppc64/page.h linus-bk-naca.1/include/asm-ppc64/page.h --- linus-bk/include/asm-ppc64/page.h 2004-10-29 07:03:22.000000000 +1000 +++ linus-bk-naca.1/include/asm-ppc64/page.h 2004-12-09 01:03:57.000000000 +1100 @@ -107,7 +107,7 @@ unsigned long lines, line_size; line_size = systemcfg->dCacheL1LineSize; - lines = naca->dCacheL1LinesPerPage; + lines = systemcfg->dCacheL1LinesPerPage; __asm__ __volatile__( "mtctr %1 # clear_page\n\ diff -ruN linus-bk/include/asm-ppc64/systemcfg.h linus-bk-naca.1/include/asm-ppc64/systemcfg.h --- linus-bk/include/asm-ppc64/systemcfg.h 2004-09-29 08:25:16.000000000 +1000 +++ linus-bk-naca.1/include/asm-ppc64/systemcfg.h 2004-12-09 01:10:58.000000000 +1100 @@ -28,7 +28,7 @@ * Minor version changes are a hint. */ #define SYSTEMCFG_MAJOR 1 -#define SYSTEMCFG_MINOR 0 +#define SYSTEMCFG_MINOR 1 #ifndef __ASSEMBLY__ @@ -54,7 +54,11 @@ __u32 dCacheL1LineSize; /* L1 d-cache line size 0x64 */ __u32 iCacheL1Size; /* L1 i-cache size 0x68 */ __u32 iCacheL1LineSize; /* L1 i-cache line size 0x6C */ - __u8 reserved0[3984]; /* Reserve rest of page 0x70 */ + __u32 dCacheL1LogLineSize; /* L1 d-cache line size Log2 0x70 */ + __u32 dCacheL1LinesPerPage; /* L1 d-cache lines / page 0x74 */ + __u32 iCacheL1LogLineSize; /* L1 i-cache line size Log2 0x78 */ + __u32 iCacheL1LinesPerPage; /* L1 i-cache lines / page 0x7c */ + __u8 reserved0[3968]; /* Reserve rest of page 0x80 */ }; #ifdef __KERNEL__ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041209/33faebe8/attachment.pgp From sfr at canb.auug.org.au Thu Dec 9 02:38:08 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 9 Dec 2004 02:38:08 +1100 Subject: naca cleanups In-Reply-To: <20041209012827.2f5be3a4.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041208140859.GB32138@krispykreme.ozlabs.ibm.com> <20041209012827.2f5be3a4.sfr@canb.auug.org.au> Message-ID: <20041209023808.3ab0a448.sfr@canb.auug.org.au> Another one for comment. This one takes usage of pftSize out of the naca. I couldn't see any reason it should not become a global vaiable. Again, the field is left there in case someone uses it from /proc/ppc64/naca. This applies on top of the previous patch. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk-naca.1/arch/ppc64/kernel/pSeries_lpar.c linus-bk-naca.2/arch/ppc64/kernel/pSeries_lpar.c --- linus-bk-naca.1/arch/ppc64/kernel/pSeries_lpar.c 2004-10-28 16:57:54.000000000 +1000 +++ linus-bk-naca.2/arch/ppc64/kernel/pSeries_lpar.c 2004-12-09 02:19:32.000000000 +1100 @@ -352,7 +352,7 @@ static void pSeries_lpar_hptab_clear(void) { - unsigned long size_bytes = 1UL << naca->pftSize; + unsigned long size_bytes = 1UL << ppc64_pft_size; unsigned long hpte_count = size_bytes >> 4; unsigned long dummy1, dummy2; int i; diff -ruN linus-bk-naca.1/arch/ppc64/kernel/prom.c linus-bk-naca.2/arch/ppc64/kernel/prom.c --- linus-bk-naca.1/arch/ppc64/kernel/prom.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.2/arch/ppc64/kernel/prom.c 2004-12-09 02:28:29.000000000 +1100 @@ -844,12 +844,12 @@ /* On LPAR, look for the first ibm,pft-size property for the hash table size */ - if (systemcfg->platform == PLATFORM_PSERIES_LPAR && naca->pftSize == 0) { + if (systemcfg->platform == PLATFORM_PSERIES_LPAR && ppc64_pft_size == 0) { u32 *pft_size; pft_size = (u32 *)get_flat_dt_prop(node, "ibm,pft-size", NULL); if (pft_size != NULL) { /* pft_size[0] is the NUMA CEC cookie */ - naca->pftSize = pft_size[1]; + naca->pftSize = ppc64_pft_size = pft_size[1]; } } @@ -1018,7 +1018,7 @@ initial_boot_params = params; /* By default, hash size is not set */ - naca->pftSize = 0; + naca->pftSize = ppc64_pft_size = 0; /* Retreive various informations from the /chosen node of the * device-tree, including the platform type, initrd location and @@ -1047,7 +1047,7 @@ /* If hash size wasn't obtained above, we calculate it now based on * the total RAM size */ - if (naca->pftSize == 0) { + if (ppc64_pft_size == 0) { unsigned long rnd_mem_size, pteg_count; /* round mem_size up to next power of 2 */ @@ -1058,10 +1058,10 @@ /* # pages / 2 */ pteg_count = (rnd_mem_size >> (12 + 1)); - naca->pftSize = __ilog2(pteg_count << 7); + naca->pftSize = ppc64_pft_size = __ilog2(pteg_count << 7); } - DBG("Hash pftSize: %x\n", (int)naca->pftSize); + DBG("Hash pftSize: %x\n", (int)ppc64_pft_size); DBG(" <- early_init_devtree()\n"); } diff -ruN linus-bk-naca.1/arch/ppc64/kernel/setup.c linus-bk-naca.2/arch/ppc64/kernel/setup.c --- linus-bk-naca.1/arch/ppc64/kernel/setup.c 2004-12-09 00:57:58.000000000 +1100 +++ linus-bk-naca.2/arch/ppc64/kernel/setup.c 2004-12-09 02:26:30.000000000 +1100 @@ -110,6 +110,7 @@ int boot_cpuid = 0; int boot_cpuid_phys = 0; dev_t boot_dev; +u64 ppc64_pft_size; /* * These are used in binfmt_elf.c to put aux entries on the stack @@ -661,7 +662,7 @@ printk("-----------------------------------------------------\n"); printk("naca = 0x%p\n", naca); - printk("naca->pftSize = 0x%lx\n", naca->pftSize); + printk("ppc64_pft_size = 0x%lx\n", ppc64_pft_size); printk("naca->debug_switch = 0x%lx\n", naca->debug_switch); printk("naca->interrupt_controller = 0x%ld\n", naca->interrupt_controller); printk("systemcfg = 0x%p\n", systemcfg); diff -ruN linus-bk-naca.1/arch/ppc64/mm/hash_utils.c linus-bk-naca.2/arch/ppc64/mm/hash_utils.c --- linus-bk-naca.1/arch/ppc64/mm/hash_utils.c 2004-10-29 07:03:21.000000000 +1000 +++ linus-bk-naca.2/arch/ppc64/mm/hash_utils.c 2004-12-09 02:16:21.000000000 +1100 @@ -147,7 +147,7 @@ * Calculate the required size of the htab. We want the number of * PTEGs to equal one half the number of real pages. */ - htab_size_bytes = 1UL << naca->pftSize; + htab_size_bytes = 1UL << ppc64_pft_size; pteg_count = htab_size_bytes >> 7; /* For debug, make the HTAB 1/8 as big as it normally would be. */ diff -ruN linus-bk-naca.1/include/asm-ppc64/naca.h linus-bk-naca.2/include/asm-ppc64/naca.h --- linus-bk-naca.1/include/asm-ppc64/naca.h 2004-09-16 21:51:58.000000000 +1000 +++ linus-bk-naca.2/include/asm-ppc64/naca.h 2004-12-09 02:14:59.000000000 +1100 @@ -11,7 +11,8 @@ */ #include -#include +#include /* for PAGE_SHIFT and KERNELBASE */ +#include #ifndef __ASSEMBLY__ @@ -31,16 +32,17 @@ u64 serialPortAddr; /* Phy addr of serial port 0x38 */ u64 interrupt_controller; /* Type of int controller 0x40 */ u64 unused1; /* was SLB size in entries 0x48 */ +/* The fields below here are unused */ u64 pftSize; /* Log 2 of page table size 0x50 */ void *systemcfg; /* Pointer to systemcfg data 0x58 */ u32 dCacheL1LogLineSize; /* L1 d-cache line size Log2 0x60 */ u32 dCacheL1LinesPerPage; /* L1 d-cache lines / page 0x64 */ u32 iCacheL1LogLineSize; /* L1 i-cache line size Log2 0x68 */ u32 iCacheL1LinesPerPage; /* L1 i-cache lines / page 0x6c */ - u8 resv0[15]; /* Reserved 0x71 - 0x7F */ }; extern struct naca_struct *naca; +extern u64 ppc64_pft_size; #endif /* __ASSEMBLY__ */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041209/41ad074d/attachment.pgp From anton at samba.org Thu Dec 9 02:43:55 2004 From: anton at samba.org (Anton Blanchard) Date: Thu, 9 Dec 2004 02:43:55 +1100 Subject: naca cleanups In-Reply-To: <20041209012827.2f5be3a4.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041208140859.GB32138@krispykreme.ozlabs.ibm.com> <20041209012827.2f5be3a4.sfr@canb.auug.org.au> Message-ID: <20041208154355.GC32138@krispykreme.ozlabs.ibm.com> Hi Stephen, > OK, so how about this as a first pass. I have left the fields in > the naca just in case something reads them out of /proc/ppc64/naca. Since we export systemcfg to userspace it might be worth keeping it out of there too (just in case someone decides to use it and we have to support it) Anton From olof at austin.ibm.com Thu Dec 9 02:51:44 2004 From: olof at austin.ibm.com (Olof Johansson) Date: Wed, 08 Dec 2004 09:51:44 -0600 Subject: naca cleanups In-Reply-To: <20041209023808.3ab0a448.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041208140859.GB32138@krispykreme.ozlabs.ibm.com> <20041209012827.2f5be3a4.sfr@canb.auug.org.au> <20041209023808.3ab0a448.sfr@canb.auug.org.au> Message-ID: <41B72310.1040407@austin.ibm.com> Stephen Rothwell wrote: >Another one for comment. This one takes usage of pftSize out of the naca. >I couldn't see any reason it should not become a global vaiable. Again, >the field is left there in case someone uses it from /proc/ppc64/naca. > > This applies to the previous patch too: How about killing the SiLlyCApS while you're at it? :) -Olof From benh at kernel.crashing.org Thu Dec 9 08:22:26 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Thu, 09 Dec 2004 08:22:26 +1100 Subject: [PATCH] ppc64: Workaround PCI issue on g5 Message-ID: <1102540946.17299.12.camel@gaston> Hi ! ppc64 has a global called "pci_probe_only" which, when set, prevents the arch PCI code from calling pci_assign_unassigned_resources(). This was cleared by pmac so far, but a bug in the definition of the variable make that ineffective until 2.6.10, and so we never called pci_assign_unassigned_resources(). With 2.6.10, that bug was fixed and so we now call it, which results in some problems. Some devices who have perfectly valid assigned addresses by firmware end up beeing moved around anyway, which is a BAD thing can can break boot on some machines since it breaks the relationship between addresses in Open Firmware device-tree and actual location of PCI devices. (Some low level things like the PIC are ioremap'ed based on their OF address, way before the PCI based ASIC hosting them has been found). This also break the "offb" default framebuffer driver since the video card ends up beeing moved around as well. For now, the fix is to set pci_probe_only on pmac, thus reverting to the old behaviour. In the long run, it would be interesting to "fix" pci_assign_unassigned_resources() so that it does what it's name claims, and only assigns things that have been left unassigned instead of moving things around gratuituously... Signed-off-by: Benjamin Herrenschmidt Index: linux-work/arch/ppc64/kernel/pmac_pci.c =================================================================== --- linux-work.orig/arch/ppc64/kernel/pmac_pci.c 2004-11-22 11:49:24.000000000 +1100 +++ linux-work/arch/ppc64/kernel/pmac_pci.c 2004-12-08 13:04:42.607006832 +1100 @@ -739,8 +739,8 @@ pmac_check_ht_link(); - /* Tell pci.c to use the common resource allocation mecanism */ - pci_probe_only = 0; + /* Tell pci.c to not use the common resource allocation mecanism */ + pci_probe_only = 1; /* Allow all IO */ io_page_mask = -1; From sfr at canb.auug.org.au Thu Dec 9 15:50:37 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 9 Dec 2004 15:50:37 +1100 Subject: [PATCH][RFC] consolidate cache sizing variables In-Reply-To: <20041209003800.7e38a32c.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> Message-ID: <20041209155037.666233c8.sfr@canb.auug.org.au> Hi all, This is a different approach to the naca cleanups. This patch puts all the variables that relate to the cache sizes into a single structure (and removes them from the naca and doesn't use them from the systemcfg any more). Please review (especially the assembler part). This builds on iSeries, pSeries and pmac, but has not been booted anywhere. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk/arch/ppc64/kernel/asm-offsets.c linus-bk-naca.1a/arch/ppc64/kernel/asm-offsets.c --- linus-bk/arch/ppc64/kernel/asm-offsets.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/asm-offsets.c 2004-12-09 14:47:31.000000000 +1100 @@ -35,6 +35,7 @@ #include #include #include +#include #define DEFINE(sym, val) \ asm volatile("\n->" #sym " %0 " #val : : "i" (val)) @@ -69,12 +70,12 @@ /* naca */ DEFINE(PACA, offsetof(struct naca_struct, paca)); - DEFINE(DCACHEL1LINESIZE, offsetof(struct systemcfg, dCacheL1LineSize)); - DEFINE(DCACHEL1LOGLINESIZE, offsetof(struct naca_struct, dCacheL1LogLineSize)); - DEFINE(DCACHEL1LINESPERPAGE, offsetof(struct naca_struct, dCacheL1LinesPerPage)); - DEFINE(ICACHEL1LINESIZE, offsetof(struct systemcfg, iCacheL1LineSize)); - DEFINE(ICACHEL1LOGLINESIZE, offsetof(struct naca_struct, iCacheL1LogLineSize)); - DEFINE(ICACHEL1LINESPERPAGE, offsetof(struct naca_struct, iCacheL1LinesPerPage)); + DEFINE(DCACHEL1LINESIZE, offsetof(struct ppc64_caches, dline_size)); + DEFINE(DCACHEL1LOGLINESIZE, offsetof(struct ppc64_caches, log_dline_size)); + DEFINE(DCACHEL1LINESPERPAGE, offsetof(struct ppc64_caches, dlines_per_page)); + DEFINE(ICACHEL1LINESIZE, offsetof(struct ppc64_caches, iline_size)); + DEFINE(ICACHEL1LOGLINESIZE, offsetof(struct ppc64_caches, log_iline_size)); + DEFINE(ICACHEL1LINESPERPAGE, offsetof(struct ppc64_caches, ilines_per_page)); DEFINE(PLATFORM, offsetof(struct systemcfg, platform)); /* paca */ diff -ruN linus-bk/arch/ppc64/kernel/eeh.c linus-bk-naca.1a/arch/ppc64/kernel/eeh.c --- linus-bk/arch/ppc64/kernel/eeh.c 2004-10-26 16:06:41.000000000 +1000 +++ linus-bk-naca.1a/arch/ppc64/kernel/eeh.c 2004-12-09 15:00:27.000000000 +1100 @@ -32,6 +32,7 @@ #include #include #include +#include #include "pci.h" #undef DEBUG diff -ruN linus-bk/arch/ppc64/kernel/iSeries_setup.c linus-bk-naca.1a/arch/ppc64/kernel/iSeries_setup.c --- linus-bk/arch/ppc64/kernel/iSeries_setup.c 2004-11-12 09:09:48.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/iSeries_setup.c 2004-12-09 14:48:09.000000000 +1100 @@ -44,6 +44,7 @@ #include "iSeries_setup.h" #include #include +#include #include #include #include @@ -560,33 +561,36 @@ unsigned int i, n; unsigned int procIx = get_paca()->lppaca.xDynHvPhysicalProcIndex; - systemcfg->iCacheL1Size = - xIoHriProcessorVpd[procIx].xInstCacheSize * 1024; - systemcfg->iCacheL1LineSize = + systemcfg->icache_size = + ppc64_caches.isize = xIoHriProcessorVpd[procIx].xInstCacheSize * 1024; + systemcfg->icache_line_size = + ppc64_caches.iline_size = xIoHriProcessorVpd[procIx].xInstCacheOperandSize; - systemcfg->dCacheL1Size = + systemcfg->dcache_size = + ppc64_caches.dsize = xIoHriProcessorVpd[procIx].xDataL1CacheSizeKB * 1024; - systemcfg->dCacheL1LineSize = + systemcfg->dcache_line_size = + ppc64_caches.dline_size = xIoHriProcessorVpd[procIx].xDataCacheOperandSize; - naca->iCacheL1LinesPerPage = PAGE_SIZE / systemcfg->iCacheL1LineSize; - naca->dCacheL1LinesPerPage = PAGE_SIZE / systemcfg->dCacheL1LineSize; + ppc64_caches.ilines_per_page = PAGE_SIZE / ppc64_caches.iline_size; + ppc64_caches.dlines_per_page = PAGE_SIZE / ppc64_caches.dline_size; - i = systemcfg->iCacheL1LineSize; + i = ppc64_caches.iline_size; n = 0; while ((i = (i / 2))) ++n; - naca->iCacheL1LogLineSize = n; + ppc64_caches.log_iline_size = n; - i = systemcfg->dCacheL1LineSize; + i = ppc64_caches.dline_size; n = 0; while ((i = (i / 2))) ++n; - naca->dCacheL1LogLineSize = n; + ppc64_caches.log_dline_size = n; printk("D-cache line size = %d\n", - (unsigned int)systemcfg->dCacheL1LineSize); + (unsigned int)ppc64_caches.dline_size); printk("I-cache line size = %d\n", - (unsigned int)systemcfg->iCacheL1LineSize); + (unsigned int)ppc64_caches.iline_size); } /* diff -ruN linus-bk/arch/ppc64/kernel/idle.c linus-bk-naca.1a/arch/ppc64/kernel/idle.c --- linus-bk/arch/ppc64/kernel/idle.c 2004-10-27 07:32:57.000000000 +1000 +++ linus-bk-naca.1a/arch/ppc64/kernel/idle.c 2004-12-09 14:56:38.000000000 +1100 @@ -32,6 +32,7 @@ #include #include #include +#include extern void power4_idle(void); diff -ruN linus-bk/arch/ppc64/kernel/misc.S linus-bk-naca.1a/arch/ppc64/kernel/misc.S --- linus-bk/arch/ppc64/kernel/misc.S 2004-11-12 09:09:48.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/misc.S 2004-12-09 13:26:26.000000000 +1100 @@ -189,6 +189,11 @@ isync blr + .section ".toc","aw" +PPC64_CACHES: + .tc ppc64_caches[TC],ppc64_caches + .section ".text" + /* * Write any modified data cache blocks out to memory * and invalidate the corresponding instruction cache blocks. @@ -207,11 +212,8 @@ * and in some cases i-cache and d-cache line sizes differ from * each other. */ - LOADADDR(r10,naca) /* Get Naca address */ - ld r10,0(r10) - LOADADDR(r11,systemcfg) /* Get systemcfg address */ - ld r11,0(r11) - lwz r7,DCACHEL1LINESIZE(r11)/* Get cache line size */ + ld r10,PPC64_CACHES at toc(r2) + lwz r7,DCACHEL1LINESIZE(r10)/* Get cache line size */ addi r5,r7,-1 andc r6,r3,r5 /* round low to line bdy */ subf r8,r6,r4 /* compute length */ @@ -227,7 +229,7 @@ /* Now invalidate the instruction cache */ - lwz r7,ICACHEL1LINESIZE(r11) /* Get Icache line size */ + lwz r7,ICACHEL1LINESIZE(r10) /* Get Icache line size */ addi r5,r7,-1 andc r6,r3,r5 /* round low to line bdy */ subf r8,r6,r4 /* compute length */ @@ -256,11 +258,8 @@ * * Different systems have different cache line sizes */ - LOADADDR(r10,naca) /* Get Naca address */ - ld r10,0(r10) - LOADADDR(r11,systemcfg) /* Get systemcfg address */ - ld r11,0(r11) - lwz r7,DCACHEL1LINESIZE(r11) /* Get dcache line size */ + ld r10,PPC64_CACHES at toc(r2) + lwz r7,DCACHEL1LINESIZE(r10) /* Get dcache line size */ addi r5,r7,-1 andc r6,r3,r5 /* round low to line bdy */ subf r8,r6,r4 /* compute length */ @@ -286,11 +285,8 @@ * flush all bytes from start to stop-1 inclusive */ _GLOBAL(flush_dcache_phys_range) - LOADADDR(r10,naca) /* Get Naca address */ - ld r10,0(r10) - LOADADDR(r11,systemcfg) /* Get systemcfg address */ - ld r11,0(r11) - lwz r7,DCACHEL1LINESIZE(r11) /* Get dcache line size */ + ld r10,PPC64_CACHES at toc(r2) + lwz r7,DCACHEL1LINESIZE(r10) /* Get dcache line size */ addi r5,r7,-1 andc r6,r3,r5 /* round low to line bdy */ subf r8,r6,r4 /* compute length */ @@ -332,13 +328,10 @@ */ /* Flush the dcache */ - LOADADDR(r7,naca) - ld r7,0(r7) - LOADADDR(r8,systemcfg) /* Get systemcfg address */ - ld r8,0(r8) + ld r7,PPC64_CACHES at toc(r2) clrrdi r3,r3,12 /* Page align */ lwz r4,DCACHEL1LINESPERPAGE(r7) /* Get # dcache lines per page */ - lwz r5,DCACHEL1LINESIZE(r8) /* Get dcache line size */ + lwz r5,DCACHEL1LINESIZE(r7) /* Get dcache line size */ mr r6,r3 mtctr r4 0: dcbst 0,r6 @@ -349,7 +342,7 @@ /* Now invalidate the icache */ lwz r4,ICACHEL1LINESPERPAGE(r7) /* Get # icache lines per page */ - lwz r5,ICACHEL1LINESIZE(r8) /* Get icache line size */ + lwz r5,ICACHEL1LINESIZE(r7) /* Get icache line size */ mtctr r4 1: icbi 0,r3 add r3,r3,r5 diff -ruN linus-bk/arch/ppc64/kernel/nvram.c linus-bk-naca.1a/arch/ppc64/kernel/nvram.c --- linus-bk/arch/ppc64/kernel/nvram.c 2004-11-16 16:05:10.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/nvram.c 2004-12-09 14:58:20.000000000 +1100 @@ -31,6 +31,7 @@ #include #include #include +#include #undef DEBUG_NVRAM diff -ruN linus-bk/arch/ppc64/kernel/pSeries_iommu.c linus-bk-naca.1a/arch/ppc64/kernel/pSeries_iommu.c --- linus-bk/arch/ppc64/kernel/pSeries_iommu.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/pSeries_iommu.c 2004-12-09 15:02:00.000000000 +1100 @@ -43,6 +43,7 @@ #include #include #include +#include #include "pci.h" diff -ruN linus-bk/arch/ppc64/kernel/pacaData.c linus-bk-naca.1a/arch/ppc64/kernel/pacaData.c --- linus-bk/arch/ppc64/kernel/pacaData.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/pacaData.c 2004-12-09 15:06:06.000000000 +1100 @@ -10,6 +10,8 @@ #include #include #include +#include + #include #include #include @@ -20,7 +22,9 @@ #include struct naca_struct *naca; +EXPORT_SYMBOL(naca); struct systemcfg *systemcfg; +EXPORT_SYMBOL(systemcfg); /* This symbol is provided by the linker - let it fill in the paca * field correctly */ diff -ruN linus-bk/arch/ppc64/kernel/pmac_setup.c linus-bk-naca.1a/arch/ppc64/kernel/pmac_setup.c --- linus-bk/arch/ppc64/kernel/pmac_setup.c 2004-10-25 18:18:33.000000000 +1000 +++ linus-bk-naca.1a/arch/ppc64/kernel/pmac_setup.c 2004-12-09 15:24:10.000000000 +1100 @@ -70,6 +70,7 @@ #include #include #include +#include #include "pmac.h" #include "mpic.h" diff -ruN linus-bk/arch/ppc64/kernel/ppc_ksyms.c linus-bk-naca.1a/arch/ppc64/kernel/ppc_ksyms.c --- linus-bk/arch/ppc64/kernel/ppc_ksyms.c 2004-10-21 07:17:18.000000000 +1000 +++ linus-bk-naca.1a/arch/ppc64/kernel/ppc_ksyms.c 2004-12-09 15:04:59.000000000 +1100 @@ -67,7 +67,6 @@ EXPORT_SYMBOL(__down_interruptible); EXPORT_SYMBOL(__up); -EXPORT_SYMBOL(naca); EXPORT_SYMBOL(__down); #ifdef CONFIG_PPC_ISERIES EXPORT_SYMBOL(itLpNaca); @@ -162,4 +161,3 @@ EXPORT_SYMBOL(tb_ticks_per_usec); EXPORT_SYMBOL(paca); EXPORT_SYMBOL(cur_cpu_spec); -EXPORT_SYMBOL(systemcfg); diff -ruN linus-bk/arch/ppc64/kernel/rtas-proc.c linus-bk-naca.1a/arch/ppc64/kernel/rtas-proc.c --- linus-bk/arch/ppc64/kernel/rtas-proc.c 2004-10-21 07:17:18.000000000 +1000 +++ linus-bk-naca.1a/arch/ppc64/kernel/rtas-proc.c 2004-12-09 15:02:27.000000000 +1100 @@ -31,6 +31,7 @@ #include #include /* for ppc_md */ #include +#include /* Token for Sensors */ #define KEY_SWITCH 0x0001 diff -ruN linus-bk/arch/ppc64/kernel/rtas.c linus-bk-naca.1a/arch/ppc64/kernel/rtas.c --- linus-bk/arch/ppc64/kernel/rtas.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/rtas.c 2004-12-09 15:01:23.000000000 +1100 @@ -29,6 +29,7 @@ #include #include #include +#include struct flash_block_list_header rtas_firmware_flash_list = {0, NULL}; diff -ruN linus-bk/arch/ppc64/kernel/rtasd.c linus-bk-naca.1a/arch/ppc64/kernel/rtasd.c --- linus-bk/arch/ppc64/kernel/rtasd.c 2004-11-16 16:05:10.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/rtasd.c 2004-12-09 15:00:50.000000000 +1100 @@ -26,6 +26,7 @@ #include #include #include +#include #if 0 #define DEBUG(A...) printk(KERN_ERR A) diff -ruN linus-bk/arch/ppc64/kernel/setup.c linus-bk-naca.1a/arch/ppc64/kernel/setup.c --- linus-bk/arch/ppc64/kernel/setup.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/setup.c 2004-12-09 14:46:37.000000000 +1100 @@ -54,6 +54,7 @@ #include #include #include +#include #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) @@ -111,6 +112,8 @@ int boot_cpuid_phys = 0; dev_t boot_dev; +struct ppc64_caches ppc64_caches; + /* * These are used in binfmt_elf.c to put aux entries on the stack * for each elf executable being started. @@ -489,15 +492,15 @@ lsizep = (u32 *) get_property(np, dc, NULL); if (lsizep != NULL) lsize = *lsizep; - if (sizep == 0 || lsizep == 0) DBG("Argh, can't find dcache properties ! " "sizep: %p, lsizep: %p\n", sizep, lsizep); - systemcfg->dCacheL1Size = size; - systemcfg->dCacheL1LineSize = lsize; - naca->dCacheL1LogLineSize = __ilog2(lsize); - naca->dCacheL1LinesPerPage = PAGE_SIZE/(lsize); + systemcfg->dcache_size = ppc64_caches.dsize = size; + systemcfg->dcache_line_size = + ppc64_caches.dline_size = lsize; + ppc64_caches.log_dline_size = __ilog2(lsize); + ppc64_caches.dlines_per_page = PAGE_SIZE / lsize; size = 0; lsize = cur_cpu_spec->icache_bsize; @@ -511,11 +514,11 @@ DBG("Argh, can't find icache properties ! " "sizep: %p, lsizep: %p\n", sizep, lsizep); - systemcfg->iCacheL1Size = size; - systemcfg->iCacheL1LineSize = lsize; - naca->iCacheL1LogLineSize = __ilog2(lsize); - naca->iCacheL1LinesPerPage = PAGE_SIZE/(lsize); - + systemcfg->icache_size = ppc64_caches.isize = size; + systemcfg->icache_line_size = + ppc64_caches.iline_size = lsize; + ppc64_caches.log_iline_size = __ilog2(lsize); + ppc64_caches.ilines_per_page = PAGE_SIZE / lsize; } } @@ -664,8 +667,10 @@ printk("systemcfg->platform = 0x%x\n", systemcfg->platform); printk("systemcfg->processorCount = 0x%lx\n", systemcfg->processorCount); printk("systemcfg->physicalMemorySize = 0x%lx\n", systemcfg->physicalMemorySize); - printk("systemcfg->dCacheL1LineSize = 0x%x\n", systemcfg->dCacheL1LineSize); - printk("systemcfg->iCacheL1LineSize = 0x%x\n", systemcfg->iCacheL1LineSize); + printk("ppc64_caches.dcache_line_size = 0x%x\n", + ppc64_caches.dline_size); + printk("ppc64_caches.icache_line_size = 0x%x\n", + ppc64_caches.iline_size); printk("htab_data.htab = 0x%p\n", htab_data.htab); printk("htab_data.num_ptegs = 0x%lx\n", htab_data.htab_num_ptegs); printk("-----------------------------------------------------\n"); @@ -1000,8 +1005,8 @@ * Systems with OF can look in the properties on the cpu node(s) * for a possibly more accurate value. */ - dcache_bsize = systemcfg->dCacheL1LineSize; - icache_bsize = systemcfg->iCacheL1LineSize; + dcache_bsize = ppc64_caches.dline_size; + icache_bsize = ppc64_caches.iline_size; /* reboot on panic */ panic_timeout = 180; diff -ruN linus-bk/arch/ppc64/kernel/sys_ppc32.c linus-bk-naca.1a/arch/ppc64/kernel/sys_ppc32.c --- linus-bk/arch/ppc64/kernel/sys_ppc32.c 2004-10-28 16:57:54.000000000 +1000 +++ linus-bk-naca.1a/arch/ppc64/kernel/sys_ppc32.c 2004-12-09 15:18:08.000000000 +1100 @@ -73,6 +73,7 @@ #include #include #include +#include #include "pci.h" diff -ruN linus-bk/arch/ppc64/kernel/sysfs.c linus-bk-naca.1a/arch/ppc64/kernel/sysfs.c --- linus-bk/arch/ppc64/kernel/sysfs.c 2004-11-16 16:05:10.000000000 +1100 +++ linus-bk-naca.1a/arch/ppc64/kernel/sysfs.c 2004-12-09 14:54:13.000000000 +1100 @@ -13,6 +13,7 @@ #include #include #include +#include /* SMT stuff */ diff -ruN linus-bk/arch/ppc64/kernel/time.c linus-bk-naca.1a/arch/ppc64/kernel/time.c --- linus-bk/arch/ppc64/kernel/time.c 2004-10-21 07:17:18.000000000 +1000 +++ linus-bk-naca.1a/arch/ppc64/kernel/time.c 2004-12-09 14:52:48.000000000 +1100 @@ -66,6 +66,7 @@ #include #include #include +#include void smp_local_timer_interrupt(struct pt_regs *); diff -ruN linus-bk/arch/ppc64/kernel/traps.c linus-bk-naca.1a/arch/ppc64/kernel/traps.c --- linus-bk/arch/ppc64/kernel/traps.c 2004-09-09 09:59:49.000000000 +1000 +++ linus-bk-naca.1a/arch/ppc64/kernel/traps.c 2004-12-09 14:49:23.000000000 +1100 @@ -37,6 +37,7 @@ #include #include #include +#include #ifdef CONFIG_PPC_PSERIES /* This is true if we are using the firmware NMI handler (typically LPAR) */ diff -ruN linus-bk/include/asm-ppc64/cache.h linus-bk-naca.1a/include/asm-ppc64/cache.h --- linus-bk/include/asm-ppc64/cache.h 2002-08-28 06:04:10.000000000 +1000 +++ linus-bk-naca.1a/include/asm-ppc64/cache.h 2004-12-09 14:51:57.000000000 +1100 @@ -7,6 +7,8 @@ #ifndef __ARCH_PPC64_CACHE_H #define __ARCH_PPC64_CACHE_H +#include + /* bytes per L1 cache line */ #define L1_CACHE_SHIFT 7 #define L1_CACHE_BYTES (1 << L1_CACHE_SHIFT) @@ -14,4 +16,21 @@ #define SMP_CACHE_BYTES L1_CACHE_BYTES #define L1_CACHE_SHIFT_MAX 7 /* largest L1 which this arch supports */ +#ifndef __ASSEMBLY__ + +struct ppc64_caches { + u32 dsize; /* L1 d-cache size */ + u32 dline_size; /* L1 d-cache line size */ + u32 log_dline_size; + u32 dlines_per_page; + u32 isize; /* L1 i-cache size */ + u32 iline_size; /* L1 i-cache line size */ + u32 log_iline_size; + u32 ilines_per_page; +}; + +extern struct ppc64_caches ppc64_caches; + +#endif + #endif diff -ruN linus-bk/include/asm-ppc64/naca.h linus-bk-naca.1a/include/asm-ppc64/naca.h --- linus-bk/include/asm-ppc64/naca.h 2004-09-16 21:51:58.000000000 +1000 +++ linus-bk-naca.1a/include/asm-ppc64/naca.h 2004-12-09 14:43:33.000000000 +1100 @@ -16,11 +16,7 @@ #ifndef __ASSEMBLY__ struct naca_struct { - /*================================================================== - * Cache line 1: 0x0000 - 0x007F - * Kernel only data - undefined for user space - *================================================================== - */ + /* Kernel only data - undefined for user space */ void *xItVpdAreas; /* VPD Data 0x00 */ void *xRamDisk; /* iSeries ramdisk 0x08 */ u64 xRamDiskSize; /* In pages 0x10 */ @@ -32,12 +28,6 @@ u64 interrupt_controller; /* Type of int controller 0x40 */ u64 unused1; /* was SLB size in entries 0x48 */ u64 pftSize; /* Log 2 of page table size 0x50 */ - void *systemcfg; /* Pointer to systemcfg data 0x58 */ - u32 dCacheL1LogLineSize; /* L1 d-cache line size Log2 0x60 */ - u32 dCacheL1LinesPerPage; /* L1 d-cache lines / page 0x64 */ - u32 iCacheL1LogLineSize; /* L1 i-cache line size Log2 0x68 */ - u32 iCacheL1LinesPerPage; /* L1 i-cache lines / page 0x6c */ - u8 resv0[15]; /* Reserved 0x71 - 0x7F */ }; extern struct naca_struct *naca; diff -ruN linus-bk/include/asm-ppc64/page.h linus-bk-naca.1a/include/asm-ppc64/page.h --- linus-bk/include/asm-ppc64/page.h 2004-10-29 07:03:22.000000000 +1000 +++ linus-bk-naca.1a/include/asm-ppc64/page.h 2004-12-09 14:44:30.000000000 +1100 @@ -93,7 +93,7 @@ #ifdef __KERNEL__ #ifndef __ASSEMBLY__ -#include +#include #undef STRICT_MM_TYPECHECKS @@ -106,8 +106,8 @@ { unsigned long lines, line_size; - line_size = systemcfg->dCacheL1LineSize; - lines = naca->dCacheL1LinesPerPage; + line_size = ppc64_caches.dline_size; + lines = ppc64_caches.dlines_per_page; __asm__ __volatile__( "mtctr %1 # clear_page\n\ diff -ruN linus-bk/include/asm-ppc64/processor.h linus-bk-naca.1a/include/asm-ppc64/processor.h --- linus-bk/include/asm-ppc64/processor.h 2004-10-27 07:32:58.000000000 +1000 +++ linus-bk-naca.1a/include/asm-ppc64/processor.h 2004-12-09 15:21:04.000000000 +1100 @@ -19,6 +19,7 @@ #endif #include #include +#include /* Machine State Register (MSR) Fields */ #define MSR_SF_LG 63 /* Enable 64 bit mode */ diff -ruN linus-bk/include/asm-ppc64/systemcfg.h linus-bk-naca.1a/include/asm-ppc64/systemcfg.h --- linus-bk/include/asm-ppc64/systemcfg.h 2004-09-29 08:25:16.000000000 +1000 +++ linus-bk-naca.1a/include/asm-ppc64/systemcfg.h 2004-12-09 15:35:41.000000000 +1100 @@ -15,14 +15,6 @@ * End Change Activity */ - -#ifndef __KERNEL__ -#include -#include -#include -#include -#endif - /* * If the major version changes we are incompatible. * Minor version changes are a hint. @@ -50,10 +42,11 @@ __u64 tb_update_count; /* Timebase atomicity ctr 0x50 */ __u32 tz_minuteswest; /* Minutes west of Greenwich 0x58 */ __u32 tz_dsttime; /* Type of dst correction 0x5C */ - __u32 dCacheL1Size; /* L1 d-cache size 0x60 */ - __u32 dCacheL1LineSize; /* L1 d-cache line size 0x64 */ - __u32 iCacheL1Size; /* L1 i-cache size 0x68 */ - __u32 iCacheL1LineSize; /* L1 i-cache line size 0x6C */ + /* next four are no longer used except to be exported to /proc */ + __u32 dcache_size; /* L1 d-cache size 0x60 */ + __u32 dcache_line_size; /* L1 d-cache line size 0x64 */ + __u32 icache_size; /* L1 i-cache size 0x68 */ + __u32 icache_line_size; /* L1 i-cache line size 0x6C */ __u8 reserved0[3984]; /* Reserve rest of page 0x70 */ }; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041209/43cf6e3e/attachment.pgp From sfr at canb.auug.org.au Thu Dec 9 17:31:35 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Thu, 9 Dec 2004 17:31:35 +1100 Subject: naca cleanups In-Reply-To: <20041209023808.3ab0a448.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041208140859.GB32138@krispykreme.ozlabs.ibm.com> <20041209012827.2f5be3a4.sfr@canb.auug.org.au> <20041209023808.3ab0a448.sfr@canb.auug.org.au> Message-ID: <20041209173135.7f90f6c4.sfr@canb.auug.org.au> On Thu, 9 Dec 2004 02:38:08 +1100 Stephen Rothwell wrote: > > Another one for comment. This one takes usage of pftSize out of the naca. > I couldn't see any reason it should not become a global vaiable. Again, > the field is left there in case someone uses it from /proc/ppc64/naca. > > This applies on top of the previous patch. New version. This build on iSeries, pSeries and pmac. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk-naca.1a/arch/ppc64/kernel/pSeries_lpar.c linus-bk-naca.2a/arch/ppc64/kernel/pSeries_lpar.c --- linus-bk-naca.1a/arch/ppc64/kernel/pSeries_lpar.c 2004-10-28 16:57:54.000000000 +1000 +++ linus-bk-naca.2a/arch/ppc64/kernel/pSeries_lpar.c 2004-12-09 17:17:35.000000000 +1100 @@ -33,7 +33,6 @@ #include #include #include -#include #include #include #include @@ -352,7 +351,7 @@ static void pSeries_lpar_hptab_clear(void) { - unsigned long size_bytes = 1UL << naca->pftSize; + unsigned long size_bytes = 1UL << ppc64_pft_size; unsigned long hpte_count = size_bytes >> 4; unsigned long dummy1, dummy2; int i; diff -ruN linus-bk-naca.1a/arch/ppc64/kernel/prom.c linus-bk-naca.2a/arch/ppc64/kernel/prom.c --- linus-bk-naca.1a/arch/ppc64/kernel/prom.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.2a/arch/ppc64/kernel/prom.c 2004-12-09 17:08:06.000000000 +1100 @@ -844,12 +844,12 @@ /* On LPAR, look for the first ibm,pft-size property for the hash table size */ - if (systemcfg->platform == PLATFORM_PSERIES_LPAR && naca->pftSize == 0) { + if (systemcfg->platform == PLATFORM_PSERIES_LPAR && ppc64_pft_size == 0) { u32 *pft_size; pft_size = (u32 *)get_flat_dt_prop(node, "ibm,pft-size", NULL); if (pft_size != NULL) { /* pft_size[0] is the NUMA CEC cookie */ - naca->pftSize = pft_size[1]; + ppc64_pft_size = pft_size[1]; } } @@ -1018,7 +1018,7 @@ initial_boot_params = params; /* By default, hash size is not set */ - naca->pftSize = 0; + ppc64_pft_size = 0; /* Retreive various informations from the /chosen node of the * device-tree, including the platform type, initrd location and @@ -1047,7 +1047,7 @@ /* If hash size wasn't obtained above, we calculate it now based on * the total RAM size */ - if (naca->pftSize == 0) { + if (ppc64_pft_size == 0) { unsigned long rnd_mem_size, pteg_count; /* round mem_size up to next power of 2 */ @@ -1058,10 +1058,10 @@ /* # pages / 2 */ pteg_count = (rnd_mem_size >> (12 + 1)); - naca->pftSize = __ilog2(pteg_count << 7); + ppc64_pft_size = __ilog2(pteg_count << 7); } - DBG("Hash pftSize: %x\n", (int)naca->pftSize); + DBG("Hash pftSize: %x\n", (int)ppc64_pft_size); DBG(" <- early_init_devtree()\n"); } diff -ruN linus-bk-naca.1a/arch/ppc64/kernel/setup.c linus-bk-naca.2a/arch/ppc64/kernel/setup.c --- linus-bk-naca.1a/arch/ppc64/kernel/setup.c 2004-12-09 14:46:37.000000000 +1100 +++ linus-bk-naca.2a/arch/ppc64/kernel/setup.c 2004-12-09 17:17:14.000000000 +1100 @@ -55,6 +55,7 @@ #include #include #include +#include #ifdef DEBUG #define DBG(fmt...) udbg_printf(fmt) @@ -111,6 +112,7 @@ int boot_cpuid = 0; int boot_cpuid_phys = 0; dev_t boot_dev; +u64 ppc64_pft_size; struct ppc64_caches ppc64_caches; @@ -660,7 +662,7 @@ printk("-----------------------------------------------------\n"); printk("naca = 0x%p\n", naca); - printk("naca->pftSize = 0x%lx\n", naca->pftSize); + printk("ppc64_pft_size = 0x%lx\n", ppc64_pft_size); printk("naca->debug_switch = 0x%lx\n", naca->debug_switch); printk("naca->interrupt_controller = 0x%ld\n", naca->interrupt_controller); printk("systemcfg = 0x%p\n", systemcfg); diff -ruN linus-bk-naca.1a/arch/ppc64/mm/hash_utils.c linus-bk-naca.2a/arch/ppc64/mm/hash_utils.c --- linus-bk-naca.1a/arch/ppc64/mm/hash_utils.c 2004-10-29 07:03:21.000000000 +1000 +++ linus-bk-naca.2a/arch/ppc64/mm/hash_utils.c 2004-12-09 17:17:54.000000000 +1100 @@ -41,7 +41,6 @@ #include #include #include -#include #include #include #include @@ -147,7 +146,7 @@ * Calculate the required size of the htab. We want the number of * PTEGs to equal one half the number of real pages. */ - htab_size_bytes = 1UL << naca->pftSize; + htab_size_bytes = 1UL << ppc64_pft_size; pteg_count = htab_size_bytes >> 7; /* For debug, make the HTAB 1/8 as big as it normally would be. */ diff -ruN linus-bk-naca.1a/include/asm-ppc64/naca.h linus-bk-naca.2a/include/asm-ppc64/naca.h --- linus-bk-naca.1a/include/asm-ppc64/naca.h 2004-12-09 14:43:33.000000000 +1100 +++ linus-bk-naca.2a/include/asm-ppc64/naca.h 2004-12-09 17:25:40.000000000 +1100 @@ -26,8 +26,6 @@ u64 log; /* Ptr to log buffer 0x30 */ u64 serialPortAddr; /* Phy addr of serial port 0x38 */ u64 interrupt_controller; /* Type of int controller 0x40 */ - u64 unused1; /* was SLB size in entries 0x48 */ - u64 pftSize; /* Log 2 of page table size 0x50 */ }; extern struct naca_struct *naca; diff -ruN linus-bk-naca.1a/include/asm-ppc64/page.h linus-bk-naca.2a/include/asm-ppc64/page.h --- linus-bk-naca.1a/include/asm-ppc64/page.h 2004-12-09 14:44:30.000000000 +1100 +++ linus-bk-naca.2a/include/asm-ppc64/page.h 2004-12-09 17:15:33.000000000 +1100 @@ -183,6 +183,8 @@ extern int page_is_ram(unsigned long pfn); +extern u64 ppc64_pft_size; /* Log 2 of page table size */ + #endif /* __ASSEMBLY__ */ #ifdef MODULE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041209/dabd65f7/attachment.pgp From anton at samba.org Fri Dec 10 03:07:05 2004 From: anton at samba.org (Anton Blanchard) Date: Fri, 10 Dec 2004 03:07:05 +1100 Subject: [PATCH] ppc64: pSeries shared processor fixes Message-ID: <20041209160705.GC24640@krispykreme.ozlabs.ibm.com> Hi, It turns out there are more issues with our VPA code: 1. vpa_init doesnt report errors when it fails. This was masking a bug where the VPA spanned 2 pages and phyp failed to register it. 2. We call idle_setup before we initialise the boot cpus vpa. This means we never select the shared processor idle loop. 3. We dont call vpa_init on UP kernels. I think this should go in ASAP, can people give it a once over? Signed-off-by: Anton Blanchard diff -puN arch/ppc64/kernel/smp.c~fix_vpa arch/ppc64/kernel/smp.c --- foobar2/arch/ppc64/kernel/smp.c~fix_vpa 2004-12-10 02:26:35.070363325 +1100 +++ foobar2-anton/arch/ppc64/kernel/smp.c 2004-12-10 02:26:35.113360044 +1100 @@ -76,8 +76,6 @@ extern unsigned char stab_array[]; extern int cpu_idle(void *unused); void smp_call_function_interrupt(void); -extern long register_vpa(unsigned long flags, unsigned long proc, - unsigned long vpa); int smt_enabled_at_boot = 1; diff -puN arch/ppc64/kernel/pSeries_smp.c~fix_vpa arch/ppc64/kernel/pSeries_smp.c --- foobar2/arch/ppc64/kernel/pSeries_smp.c~fix_vpa 2004-12-10 02:26:35.075362944 +1100 +++ foobar2-anton/arch/ppc64/kernel/pSeries_smp.c 2004-12-10 02:26:35.115359891 +1100 @@ -59,16 +59,6 @@ extern void pseries_secondary_smp_init(unsigned long); -static void vpa_init(int cpu) -{ - unsigned long flags, pcpu = get_hard_smp_processor_id(cpu); - - /* Register the Virtual Processor Area (VPA) */ - flags = 1UL << (63 - 18); - register_vpa(flags, pcpu, __pa((unsigned long)&(paca[cpu].lppaca))); -} - - /* Get state of physical CPU. * Return codes: * 0 - The processor is in the RTAS stopped state diff -puN arch/ppc64/kernel/setup.c~fix_vpa arch/ppc64/kernel/setup.c --- foobar2/arch/ppc64/kernel/setup.c~fix_vpa 2004-12-10 02:26:35.081362486 +1100 +++ foobar2-anton/arch/ppc64/kernel/setup.c 2004-12-10 02:26:35.118359662 +1100 @@ -1020,11 +1020,11 @@ void __init setup_arch(char **cmdline_p) /* set up the bootmem stuff with available memory */ do_init_bootmem(); + ppc_md.setup_arch(); + /* Select the correct idle loop for the platform. */ idle_setup(); - ppc_md.setup_arch(); - paging_init(); ppc64_boot_msg(0x15, "Setup Done"); } diff -puN arch/ppc64/kernel/pSeries_setup.c~fix_vpa arch/ppc64/kernel/pSeries_setup.c --- foobar2/arch/ppc64/kernel/pSeries_setup.c~fix_vpa 2004-12-10 02:26:35.085362180 +1100 +++ foobar2-anton/arch/ppc64/kernel/pSeries_setup.c 2004-12-10 02:26:35.120359510 +1100 @@ -234,6 +234,9 @@ static void __init pSeries_setup_arch(vo #endif pSeries_nvram_init(); + + if (cur_cpu_spec->firmware_features & FW_FEATURE_SPLPAR) + vpa_init(boot_cpuid); } static int __init pSeries_init_panel(void) diff -puN include/asm-ppc64/plpar_wrappers.h~fix_vpa include/asm-ppc64/plpar_wrappers.h --- foobar2/include/asm-ppc64/plpar_wrappers.h~fix_vpa 2004-12-10 02:26:35.090361799 +1100 +++ foobar2-anton/include/asm-ppc64/plpar_wrappers.h 2004-12-10 02:26:35.121359433 +1100 @@ -22,12 +22,14 @@ static inline long cede_processor(void) return(0); } -static inline long register_vpa(unsigned long flags, unsigned long proc, unsigned long vpa) +static inline long register_vpa(unsigned long flags, unsigned long proc, + unsigned long vpa) { - plpar_hcall_norets(H_REGISTER_VPA, flags, proc, vpa); - return(0); + return plpar_hcall_norets(H_REGISTER_VPA, flags, proc, vpa); } +void vpa_init(int cpu); + static inline long plpar_pte_remove(unsigned long flags, unsigned long ptex, unsigned long avpn, diff -puN arch/ppc64/kernel/pSeries_lpar.c~fix_vpa arch/ppc64/kernel/pSeries_lpar.c --- foobar2/arch/ppc64/kernel/pSeries_lpar.c~fix_vpa 2004-12-10 02:26:35.095361417 +1100 +++ foobar2-anton/arch/ppc64/kernel/pSeries_lpar.c 2004-12-10 02:55:47.622076537 +1100 @@ -259,6 +259,22 @@ out: return found; } +void vpa_init(int cpu) +{ + int hwcpu = get_hard_smp_processor_id(cpu); + unsigned long vpa = (unsigned long)&(paca[cpu].lppaca); + long ret; + unsigned long flags; + + /* Register the Virtual Processor Area (VPA) */ + flags = 1UL << (63 - 18); + ret = register_vpa(flags, hwcpu, __pa(vpa)); + + if (ret) + printk(KERN_ERR "WARNING: vpa_init: VPA registration for " + "cpu %d (hw %d) of area %lx returns %ld\n", + cpu, hwcpu, __pa(vpa), ret); +} long pSeries_lpar_hpte_insert(unsigned long hpte_group, unsigned long va, unsigned long prpn, _ From jschopp at austin.ibm.com Fri Dec 10 04:25:22 2004 From: jschopp at austin.ibm.com (Joel Schopp) Date: Thu, 09 Dec 2004 11:25:22 -0600 Subject: [PATCH] ppc64: pSeries shared processor fixes In-Reply-To: <20041209160705.GC24640@krispykreme.ozlabs.ibm.com> References: <20041209160705.GC24640@krispykreme.ozlabs.ibm.com> Message-ID: <41B88A82.20003@austin.ibm.com> > Hi, > > It turns out there are more issues with our VPA code: > > 1. vpa_init doesnt report errors when it fails. This was masking a bug > where the VPA spanned 2 pages and phyp failed to register it. > 2. We call idle_setup before we initialise the boot cpus vpa. This means > we never select the shared processor idle loop. > 3. We dont call vpa_init on UP kernels. > > I think this should go in ASAP, can people give it a once over? Wow. We really weren't ever using shared idle. Now that we actually are do you think some performance team somewhere would be interested to test that it is worthwhile? Have you tested it at all from a performance perspective? The patch looks good to me. On a somewhat related note, I never have liked that plpar_hcall_norets() actually returns status. Seems poorly named to me. -Joel > > Signed-off-by: Anton Blanchard > > diff -puN arch/ppc64/kernel/smp.c~fix_vpa arch/ppc64/kernel/smp.c > --- foobar2/arch/ppc64/kernel/smp.c~fix_vpa 2004-12-10 02:26:35.070363325 +1100 > +++ foobar2-anton/arch/ppc64/kernel/smp.c 2004-12-10 02:26:35.113360044 +1100 > @@ -76,8 +76,6 @@ extern unsigned char stab_array[]; > > extern int cpu_idle(void *unused); > void smp_call_function_interrupt(void); > -extern long register_vpa(unsigned long flags, unsigned long proc, > - unsigned long vpa); > > int smt_enabled_at_boot = 1; > > diff -puN arch/ppc64/kernel/pSeries_smp.c~fix_vpa arch/ppc64/kernel/pSeries_smp.c > --- foobar2/arch/ppc64/kernel/pSeries_smp.c~fix_vpa 2004-12-10 02:26:35.075362944 +1100 > +++ foobar2-anton/arch/ppc64/kernel/pSeries_smp.c 2004-12-10 02:26:35.115359891 +1100 > @@ -59,16 +59,6 @@ > > extern void pseries_secondary_smp_init(unsigned long); > > -static void vpa_init(int cpu) > -{ > - unsigned long flags, pcpu = get_hard_smp_processor_id(cpu); > - > - /* Register the Virtual Processor Area (VPA) */ > - flags = 1UL << (63 - 18); > - register_vpa(flags, pcpu, __pa((unsigned long)&(paca[cpu].lppaca))); > -} > - > - > /* Get state of physical CPU. > * Return codes: > * 0 - The processor is in the RTAS stopped state > diff -puN arch/ppc64/kernel/setup.c~fix_vpa arch/ppc64/kernel/setup.c > --- foobar2/arch/ppc64/kernel/setup.c~fix_vpa 2004-12-10 02:26:35.081362486 +1100 > +++ foobar2-anton/arch/ppc64/kernel/setup.c 2004-12-10 02:26:35.118359662 +1100 > @@ -1020,11 +1020,11 @@ void __init setup_arch(char **cmdline_p) > /* set up the bootmem stuff with available memory */ > do_init_bootmem(); > > + ppc_md.setup_arch(); > + > /* Select the correct idle loop for the platform. */ > idle_setup(); > > - ppc_md.setup_arch(); > - > paging_init(); > ppc64_boot_msg(0x15, "Setup Done"); > } > diff -puN arch/ppc64/kernel/pSeries_setup.c~fix_vpa arch/ppc64/kernel/pSeries_setup.c > --- foobar2/arch/ppc64/kernel/pSeries_setup.c~fix_vpa 2004-12-10 02:26:35.085362180 +1100 > +++ foobar2-anton/arch/ppc64/kernel/pSeries_setup.c 2004-12-10 02:26:35.120359510 +1100 > @@ -234,6 +234,9 @@ static void __init pSeries_setup_arch(vo > #endif > > pSeries_nvram_init(); > + > + if (cur_cpu_spec->firmware_features & FW_FEATURE_SPLPAR) > + vpa_init(boot_cpuid); > } > > static int __init pSeries_init_panel(void) > diff -puN include/asm-ppc64/plpar_wrappers.h~fix_vpa include/asm-ppc64/plpar_wrappers.h > --- foobar2/include/asm-ppc64/plpar_wrappers.h~fix_vpa 2004-12-10 02:26:35.090361799 +1100 > +++ foobar2-anton/include/asm-ppc64/plpar_wrappers.h 2004-12-10 02:26:35.121359433 +1100 > @@ -22,12 +22,14 @@ static inline long cede_processor(void) > return(0); > } > > -static inline long register_vpa(unsigned long flags, unsigned long proc, unsigned long vpa) > +static inline long register_vpa(unsigned long flags, unsigned long proc, > + unsigned long vpa) > { > - plpar_hcall_norets(H_REGISTER_VPA, flags, proc, vpa); > - return(0); > + return plpar_hcall_norets(H_REGISTER_VPA, flags, proc, vpa); > } > > +void vpa_init(int cpu); > + > static inline long plpar_pte_remove(unsigned long flags, > unsigned long ptex, > unsigned long avpn, > diff -puN arch/ppc64/kernel/pSeries_lpar.c~fix_vpa arch/ppc64/kernel/pSeries_lpar.c > --- foobar2/arch/ppc64/kernel/pSeries_lpar.c~fix_vpa 2004-12-10 02:26:35.095361417 +1100 > +++ foobar2-anton/arch/ppc64/kernel/pSeries_lpar.c 2004-12-10 02:55:47.622076537 +1100 > @@ -259,6 +259,22 @@ out: > return found; > } > > +void vpa_init(int cpu) > +{ > + int hwcpu = get_hard_smp_processor_id(cpu); > + unsigned long vpa = (unsigned long)&(paca[cpu].lppaca); > + long ret; > + unsigned long flags; > + > + /* Register the Virtual Processor Area (VPA) */ > + flags = 1UL << (63 - 18); > + ret = register_vpa(flags, hwcpu, __pa(vpa)); > + > + if (ret) > + printk(KERN_ERR "WARNING: vpa_init: VPA registration for " > + "cpu %d (hw %d) of area %lx returns %ld\n", > + cpu, hwcpu, __pa(vpa), ret); > +} > > long pSeries_lpar_hpte_insert(unsigned long hpte_group, > unsigned long va, unsigned long prpn, > _ > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/cgi-bin/mailman/listinfo/linuxppc64-dev > From nathanl at austin.ibm.com Fri Dec 10 05:03:06 2004 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Thu, 09 Dec 2004 12:03:06 -0600 Subject: [PATCH] ppc64: pSeries shared processor fixes In-Reply-To: <41B88A82.20003@austin.ibm.com> References: <20041209160705.GC24640@krispykreme.ozlabs.ibm.com> <41B88A82.20003@austin.ibm.com> Message-ID: <1102615386.13574.10.camel@localhost.localdomain> On Thu, 2004-12-09 at 11:25 -0600, Joel Schopp wrote: > > Hi, > > > > It turns out there are more issues with our VPA code: > > > > 1. vpa_init doesnt report errors when it fails. This was masking a bug > > where the VPA spanned 2 pages and phyp failed to register it. > > 2. We call idle_setup before we initialise the boot cpus vpa. This means > > we never select the shared processor idle loop. > > 3. We dont call vpa_init on UP kernels. > > > > I think this should go in ASAP, can people give it a once over? > > Wow. We really weren't ever using shared idle. IIRC it was working around the 2.6.5 or 2.6.6 timeframe. I think it's likely that some of the code reorganizations and cleanups that have gone in since then introduced the bug. Nathan From sfr at canb.auug.org.au Fri Dec 10 15:15:47 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Fri, 10 Dec 2004 15:15:47 +1100 Subject: [PATCH][RFC] more naca cleanups In-Reply-To: <20041209155037.666233c8.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041209155037.666233c8.sfr@canb.auug.org.au> Message-ID: <20041210151547.6c847cb5.sfr@canb.auug.org.au> Hi all, This patch moves interrupt_controller out of the naca. It applies on top of the other two. It builds on iSeries, pSeries and pmac and has been test booted on a pSeries (44P 270). -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/irq.c linus-bk-naca.3a/arch/ppc64/kernel/irq.c --- linus-bk-naca.2a/arch/ppc64/kernel/irq.c 2004-10-21 07:17:18.000000000 +1000 +++ linus-bk-naca.3a/arch/ppc64/kernel/irq.c 2004-12-09 02:50:34.000000000 +1100 @@ -65,6 +65,7 @@ int __irq_offset_value; int ppc_spurious_interrupts; unsigned long lpevent_count; +u64 ppc64_interrupt_controller; int show_interrupts(struct seq_file *p, void *v) { @@ -360,7 +361,7 @@ unsigned int virq, first_virq; static int warned; - if (naca->interrupt_controller == IC_OPEN_PIC) + if (ppc64_interrupt_controller == IC_OPEN_PIC) return real_irq; /* no mapping for openpic (for now) */ /* don't map interrupts < MIN_VIRT_IRQ */ diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/maple_setup.c linus-bk-naca.3a/arch/ppc64/kernel/maple_setup.c --- linus-bk-naca.2a/arch/ppc64/kernel/maple_setup.c 2004-10-30 08:33:22.000000000 +1000 +++ linus-bk-naca.3a/arch/ppc64/kernel/maple_setup.c 2004-12-10 12:02:32.000000000 +1100 @@ -155,7 +155,7 @@ } /* Setup interrupt mapping options */ - naca->interrupt_controller = IC_OPEN_PIC; + ppc64_interrupt_controller = IC_OPEN_PIC; DBG(" <- maple_init_early\n"); } diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/pSeries_pci.c linus-bk-naca.3a/arch/ppc64/kernel/pSeries_pci.c --- linus-bk-naca.2a/arch/ppc64/kernel/pSeries_pci.c 2004-11-16 16:05:10.000000000 +1100 +++ linus-bk-naca.3a/arch/ppc64/kernel/pSeries_pci.c 2004-12-09 02:58:40.000000000 +1100 @@ -353,7 +353,7 @@ unsigned int *opprop = NULL; struct device_node *root = of_find_node_by_path("/"); - if (naca->interrupt_controller == IC_OPEN_PIC) { + if (ppc64_interrupt_controller == IC_OPEN_PIC) { opprop = (unsigned int *)get_property(root, "platform-open-pic", NULL); } @@ -375,7 +375,7 @@ pci_process_bridge_OF_ranges(phb, node); pci_setup_phb_io(phb, index == 0); - if (naca->interrupt_controller == IC_OPEN_PIC && pSeries_mpic) { + if (ppc64_interrupt_controller == IC_OPEN_PIC && pSeries_mpic) { int addr = root_size_cells * (index + 2) - 1; mpic_assign_isu(pSeries_mpic, index, opprop[addr]); } diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/pSeries_setup.c linus-bk-naca.3a/arch/ppc64/kernel/pSeries_setup.c --- linus-bk-naca.2a/arch/ppc64/kernel/pSeries_setup.c 2004-10-26 16:06:41.000000000 +1000 +++ linus-bk-naca.3a/arch/ppc64/kernel/pSeries_setup.c 2004-12-10 12:11:14.000000000 +1100 @@ -196,7 +196,7 @@ static void __init pSeries_setup_arch(void) { /* Fixup ppc_md depending on the type of interrupt controller */ - if (naca->interrupt_controller == IC_OPEN_PIC) { + if (ppc64_interrupt_controller == IC_OPEN_PIC) { ppc_md.init_IRQ = pSeries_init_mpic; ppc_md.get_irq = mpic_get_irq; /* Allocate the mpic now, so that find_and_init_phbs() can @@ -305,13 +305,13 @@ * to properly parse the OF interrupt tree & do the virtual irq mapping */ __irq_offset_value = NUM_ISA_INTERRUPTS; - naca->interrupt_controller = IC_INVALID; + ppc64_interrupt_controller = IC_INVALID; for (np = NULL; (np = of_find_node_by_name(np, "interrupt-controller"));) { typep = (char *)get_property(np, "compatible", NULL); if (strstr(typep, "open-pic")) - naca->interrupt_controller = IC_OPEN_PIC; + ppc64_interrupt_controller = IC_OPEN_PIC; else if (strstr(typep, "ppc-xicp")) - naca->interrupt_controller = IC_PPC_XIC; + ppc64_interrupt_controller = IC_PPC_XIC; else printk("initialize_naca: failed to recognize" " interrupt-controller\n"); diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/pSeries_smp.c linus-bk-naca.3a/arch/ppc64/kernel/pSeries_smp.c --- linus-bk-naca.2a/arch/ppc64/kernel/pSeries_smp.c 2004-11-12 09:09:48.000000000 +1100 +++ linus-bk-naca.3a/arch/ppc64/kernel/pSeries_smp.c 2004-12-09 03:01:03.000000000 +1100 @@ -358,7 +358,7 @@ DBG(" -> smp_init_pSeries()\n"); - if (naca->interrupt_controller == IC_OPEN_PIC) + if (ppc64_interrupt_controller == IC_OPEN_PIC) smp_ops = &pSeries_mpic_smp_ops; else smp_ops = &pSeries_xics_smp_ops; diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/pmac_setup.c linus-bk-naca.3a/arch/ppc64/kernel/pmac_setup.c --- linus-bk-naca.2a/arch/ppc64/kernel/pmac_setup.c 2004-12-09 15:24:10.000000000 +1100 +++ linus-bk-naca.3a/arch/ppc64/kernel/pmac_setup.c 2004-12-10 12:00:55.000000000 +1100 @@ -70,7 +70,6 @@ #include #include #include -#include #include "pmac.h" #include "mpic.h" @@ -316,7 +315,7 @@ } /* Setup interrupt mapping options */ - naca->interrupt_controller = IC_OPEN_PIC; + ppc64_interrupt_controller = IC_OPEN_PIC; DBG(" <- pmac_init_early\n"); } diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/prom.c linus-bk-naca.3a/arch/ppc64/kernel/prom.c --- linus-bk-naca.2a/arch/ppc64/kernel/prom.c 2004-12-09 17:08:06.000000000 +1100 +++ linus-bk-naca.3a/arch/ppc64/kernel/prom.c 2004-12-10 12:04:58.000000000 +1100 @@ -44,7 +44,6 @@ #include #include #include -#include #include #include #include @@ -557,7 +556,7 @@ DBG(" -> finish_device_tree\n"); - if (naca->interrupt_controller == IC_INVALID) { + if (ppc64_interrupt_controller == IC_INVALID) { DBG("failed to configure interrupt controller type\n"); panic("failed to configure interrupt controller type\n"); } diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/setup.c linus-bk-naca.3a/arch/ppc64/kernel/setup.c --- linus-bk-naca.2a/arch/ppc64/kernel/setup.c 2004-12-09 17:17:14.000000000 +1100 +++ linus-bk-naca.3a/arch/ppc64/kernel/setup.c 2004-12-10 12:06:07.000000000 +1100 @@ -664,7 +664,7 @@ printk("naca = 0x%p\n", naca); printk("ppc64_pft_size = 0x%lx\n", ppc64_pft_size); printk("naca->debug_switch = 0x%lx\n", naca->debug_switch); - printk("naca->interrupt_controller = 0x%ld\n", naca->interrupt_controller); + printk("ppc64_interrupt_controller = 0x%ld\n", ppc64_interrupt_controller); printk("systemcfg = 0x%p\n", systemcfg); printk("systemcfg->platform = 0x%x\n", systemcfg->platform); printk("systemcfg->processorCount = 0x%lx\n", systemcfg->processorCount); diff -ruN linus-bk-naca.2a/arch/ppc64/kernel/xics.c linus-bk-naca.3a/arch/ppc64/kernel/xics.c --- linus-bk-naca.2a/arch/ppc64/kernel/xics.c 2004-10-27 07:32:57.000000000 +1000 +++ linus-bk-naca.3a/arch/ppc64/kernel/xics.c 2004-12-10 12:06:57.000000000 +1100 @@ -24,7 +24,6 @@ #include #include #include -#include #include #include #include @@ -575,7 +574,7 @@ */ static int __init xics_setup_i8259(void) { - if (naca->interrupt_controller == IC_PPC_XIC && + if (ppc64_interrupt_controller == IC_PPC_XIC && xics_irq_8259_cascade != -1) { if (request_irq(irq_offset_up(xics_irq_8259_cascade), no_action, 0, "8259 cascade", NULL)) diff -ruN linus-bk-naca.2a/include/asm-ppc64/naca.h linus-bk-naca.3a/include/asm-ppc64/naca.h --- linus-bk-naca.2a/include/asm-ppc64/naca.h 2004-12-09 17:25:40.000000000 +1100 +++ linus-bk-naca.3a/include/asm-ppc64/naca.h 2004-12-10 12:07:56.000000000 +1100 @@ -25,7 +25,6 @@ u64 banner; /* Ptr to banner string 0x28 */ u64 log; /* Ptr to log buffer 0x30 */ u64 serialPortAddr; /* Phy addr of serial port 0x38 */ - u64 interrupt_controller; /* Type of int controller 0x40 */ }; extern struct naca_struct *naca; diff -ruN linus-bk-naca.2a/include/asm-ppc64/processor.h linus-bk-naca.3a/include/asm-ppc64/processor.h --- linus-bk-naca.2a/include/asm-ppc64/processor.h 2004-12-09 15:21:04.000000000 +1100 +++ linus-bk-naca.3a/include/asm-ppc64/processor.h 2004-12-10 12:08:33.000000000 +1100 @@ -484,6 +484,7 @@ #ifdef __KERNEL__ extern int have_of; +extern u64 ppc64_interrupt_controller; struct task_struct; void start_thread(struct pt_regs *regs, unsigned long fdptr, unsigned long sp); -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041210/f68b87b6/attachment.pgp From sfr at canb.auug.org.au Fri Dec 10 16:03:22 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Fri, 10 Dec 2004 16:03:22 +1100 Subject: [PATCH][RFC] remove /proc/ppc64/[np]aca In-Reply-To: <20041210151547.6c847cb5.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041209155037.666233c8.sfr@canb.auug.org.au> <20041210151547.6c847cb5.sfr@canb.auug.org.au> Message-ID: <20041210160322.1dcb659d.sfr@canb.auug.org.au> Hi all, Paulus suggested that we don't need to expose the naca or the pacas to usermode, so here is the patch that removes them. It also removes all the unnecessary #includes of naca.h and paca.h. Build on iSeries, pSeries and pmac. Boots on pSeries (44P 270). -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/iSeries_pci.c linus-bk-naca.4a/arch/ppc64/kernel/iSeries_pci.c --- linus-bk-naca.3a/arch/ppc64/kernel/iSeries_pci.c 2004-11-16 16:05:10.000000000 +1100 +++ linus-bk-naca.4a/arch/ppc64/kernel/iSeries_pci.c 2004-12-10 15:34:05.000000000 +1100 @@ -35,7 +35,6 @@ #include #include #include -#include #include #include diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/iSeries_proc.c linus-bk-naca.4a/arch/ppc64/kernel/iSeries_proc.c --- linus-bk-naca.3a/arch/ppc64/kernel/iSeries_proc.c 2004-10-22 07:00:21.000000000 +1000 +++ linus-bk-naca.4a/arch/ppc64/kernel/iSeries_proc.c 2004-12-10 15:34:33.000000000 +1100 @@ -24,7 +24,6 @@ #include #include #include -#include #include #include #include diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/iSeries_smp.c linus-bk-naca.4a/arch/ppc64/kernel/iSeries_smp.c --- linus-bk-naca.3a/arch/ppc64/kernel/iSeries_smp.c 2004-10-30 08:33:22.000000000 +1000 +++ linus-bk-naca.4a/arch/ppc64/kernel/iSeries_smp.c 2004-12-10 15:41:54.000000000 +1100 @@ -37,7 +37,6 @@ #include #include #include -#include #include #include #include diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/pSeries_pci.c linus-bk-naca.4a/arch/ppc64/kernel/pSeries_pci.c --- linus-bk-naca.3a/arch/ppc64/kernel/pSeries_pci.c 2004-12-09 02:58:40.000000000 +1100 +++ linus-bk-naca.4a/arch/ppc64/kernel/pSeries_pci.c 2004-12-10 15:32:47.000000000 +1100 @@ -36,7 +36,6 @@ #include #include #include -#include #include #include diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/pSeries_smp.c linus-bk-naca.4a/arch/ppc64/kernel/pSeries_smp.c --- linus-bk-naca.3a/arch/ppc64/kernel/pSeries_smp.c 2004-12-09 03:01:03.000000000 +1100 +++ linus-bk-naca.4a/arch/ppc64/kernel/pSeries_smp.c 2004-12-10 15:33:26.000000000 +1100 @@ -38,7 +38,6 @@ #include #include #include -#include #include #include #include diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/pci_dn.c linus-bk-naca.4a/arch/ppc64/kernel/pci_dn.c --- linus-bk-naca.3a/arch/ppc64/kernel/pci_dn.c 2004-10-25 18:18:33.000000000 +1000 +++ linus-bk-naca.4a/arch/ppc64/kernel/pci_dn.c 2004-12-10 15:33:44.000000000 +1100 @@ -33,7 +33,6 @@ #include #include #include -#include #include #include "pci.h" diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/proc_ppc64.c linus-bk-naca.4a/arch/ppc64/kernel/proc_ppc64.c --- linus-bk-naca.3a/arch/ppc64/kernel/proc_ppc64.c 2004-10-27 07:32:57.000000000 +1000 +++ linus-bk-naca.4a/arch/ppc64/kernel/proc_ppc64.c 2004-12-10 15:44:59.000000000 +1100 @@ -25,8 +25,6 @@ #include #include -#include -#include #include #include #include @@ -58,26 +56,6 @@ #endif /* - * NOTE: since paca data is always in flux the values will never be a - * consistant set. - */ -static void __init proc_create_paca(struct proc_dir_entry *dir, int num) -{ - struct proc_dir_entry *ent; - struct paca_struct *lpaca = paca + num; - char buf[16]; - - sprintf(buf, "%02x", num); - ent = create_proc_entry(buf, S_IRUSR, dir); - if (ent) { - ent->nlink = 1; - ent->data = lpaca; - ent->size = 4096; - ent->proc_fops = &page_map_fops; - } -} - -/* * Create the ppc64 and ppc64/rtas directories early. This allows us to * assume that they have been previously created in drivers. */ @@ -104,17 +82,8 @@ static int __init proc_ppc64_init(void) { - unsigned long i; struct proc_dir_entry *pde; - pde = create_proc_entry("ppc64/naca", S_IRUSR, NULL); - if (!pde) - return 1; - pde->nlink = 1; - pde->data = naca; - pde->size = 4096; - pde->proc_fops = &page_map_fops; - pde = create_proc_entry("ppc64/systemcfg", S_IFREG|S_IRUGO, NULL); if (!pde) return 1; @@ -123,13 +92,6 @@ pde->size = 4096; pde->proc_fops = &page_map_fops; - /* /proc/ppc64/paca/XX -- raw paca contents. Only readable to root */ - pde = proc_mkdir("ppc64/paca", NULL); - if (!pde) - return 1; - for_each_cpu(i) - proc_create_paca(pde, i); - #ifdef CONFIG_PPC_PSERIES if ((systemcfg->platform & PLATFORM_PSERIES)) proc_ppc64_create_ofdt(); diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/prom_init.c linus-bk-naca.4a/arch/ppc64/kernel/prom_init.c --- linus-bk-naca.3a/arch/ppc64/kernel/prom_init.c 2004-12-08 12:07:34.000000000 +1100 +++ linus-bk-naca.4a/arch/ppc64/kernel/prom_init.c 2004-12-10 15:41:28.000000000 +1100 @@ -43,7 +43,6 @@ #include #include #include -#include #include #include #include diff -ruN linus-bk-naca.3a/arch/ppc64/kernel/smp.c linus-bk-naca.4a/arch/ppc64/kernel/smp.c --- linus-bk-naca.3a/arch/ppc64/kernel/smp.c 2004-10-25 18:18:33.000000000 +1000 +++ linus-bk-naca.4a/arch/ppc64/kernel/smp.c 2004-12-10 15:22:44.000000000 +1100 @@ -41,7 +41,6 @@ #include #include #include -#include #include #include #include diff -ruN linus-bk-naca.3a/arch/ppc64/mm/init.c linus-bk-naca.4a/arch/ppc64/mm/init.c --- linus-bk-naca.3a/arch/ppc64/mm/init.c 2004-11-04 16:05:08.000000000 +1100 +++ linus-bk-naca.4a/arch/ppc64/mm/init.c 2004-12-10 15:42:19.000000000 +1100 @@ -52,7 +52,6 @@ #include #include #include -#include #include #include #include diff -ruN linus-bk-naca.3a/arch/ppc64/mm/slb.c linus-bk-naca.4a/arch/ppc64/mm/slb.c --- linus-bk-naca.3a/arch/ppc64/mm/slb.c 2004-09-06 10:19:04.000000000 +1000 +++ linus-bk-naca.4a/arch/ppc64/mm/slb.c 2004-12-10 15:42:40.000000000 +1100 @@ -19,7 +19,6 @@ #include #include #include -#include #include extern void slb_allocate(unsigned long ea); diff -ruN linus-bk-naca.3a/arch/ppc64/mm/stab.c linus-bk-naca.4a/arch/ppc64/mm/stab.c --- linus-bk-naca.3a/arch/ppc64/mm/stab.c 2004-09-16 21:51:57.000000000 +1000 +++ linus-bk-naca.4a/arch/ppc64/mm/stab.c 2004-12-10 15:43:05.000000000 +1100 @@ -17,7 +17,6 @@ #include #include #include -#include #include /* Both the segment table and SLB code uses the following cache */ diff -ruN linus-bk-naca.3a/include/asm-ppc64/iSeries/LparData.h linus-bk-naca.4a/include/asm-ppc64/iSeries/LparData.h --- linus-bk-naca.3a/include/asm-ppc64/iSeries/LparData.h 2002-09-18 12:00:50.000000000 +1000 +++ linus-bk-naca.4a/include/asm-ppc64/iSeries/LparData.h 2004-12-10 15:43:54.000000000 +1100 @@ -24,11 +24,9 @@ #include #include -#include #include #include #include -#include #include #include #include -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041210/deab33c5/attachment.pgp From sfr at canb.auug.org.au Fri Dec 10 18:48:37 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Fri, 10 Dec 2004 18:48:37 +1100 Subject: [PATCH][RFC] remove paca pointer from the naca In-Reply-To: <20041210160322.1dcb659d.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041209155037.666233c8.sfr@canb.auug.org.au> <20041210151547.6c847cb5.sfr@canb.auug.org.au> <20041210160322.1dcb659d.sfr@canb.auug.org.au> Message-ID: <20041210184837.26a1cddc.sfr@canb.auug.org.au> Hi all, This patch just removes the paca pointer from the naca (and the one reference to it). It turns out that it was just there so that the iSeries startup code could find the paca in order to pass a member of it to iSeries_early_init - which now takes no arguments ... Built and booted on iSeries (which is the only thing affected). Built on pSeries and pmac. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk-naca.4/arch/ppc64/kernel/asm-offsets.c linus-bk-naca.5/arch/ppc64/kernel/asm-offsets.c --- linus-bk-naca.4/arch/ppc64/kernel/asm-offsets.c 2004-12-10 16:26:44.000000000 +1100 +++ linus-bk-naca.5/arch/ppc64/kernel/asm-offsets.c 2004-12-10 17:27:14.000000000 +1100 @@ -28,7 +28,6 @@ #include #include -#include #include #include #include @@ -68,8 +67,6 @@ #endif /* CONFIG_ALTIVEC */ DEFINE(MM, offsetof(struct task_struct, mm)); - /* naca */ - DEFINE(PACA, offsetof(struct naca_struct, paca)); DEFINE(DCACHEL1LINESIZE, offsetof(struct ppc64_caches, dline_size)); DEFINE(DCACHEL1LOGLINESIZE, offsetof(struct ppc64_caches, log_dline_size)); DEFINE(DCACHEL1LINESPERPAGE, offsetof(struct ppc64_caches, dlines_per_page)); diff -ruN linus-bk-naca.4/arch/ppc64/kernel/head.S linus-bk-naca.5/arch/ppc64/kernel/head.S --- linus-bk-naca.4/arch/ppc64/kernel/head.S 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.5/arch/ppc64/kernel/head.S 2004-12-10 18:40:24.000000000 +1100 @@ -517,12 +517,7 @@ __start_naca: #ifdef CONFIG_PPC_ISERIES .llong itVpdAreas -#else - .llong 0x0 #endif - .llong 0x0 - .llong 0x0 - .llong paca . = SYSTEMCFG_PHYS_ADDR .globl __end_naca @@ -1241,6 +1236,7 @@ #endif #endif b 3b /* Loop until told to go */ + #ifdef CONFIG_PPC_ISERIES _STATIC(__start_initialization_iSeries) /* Clear out the BSS */ @@ -1278,10 +1274,6 @@ SET_REG_TO_CONST(r4, NACA_VIRT_ADDR) std r4,0(r9) /* set the naca pointer */ - /* Get the pointer to the segment table */ - ld r6,PACA(r4) /* Get the base paca pointer */ - ld r4,PACASTABVIRT(r6) - bl .iSeries_early_setup /* relocation is on at this point */ diff -ruN linus-bk-naca.4/include/asm-ppc64/naca.h linus-bk-naca.5/include/asm-ppc64/naca.h --- linus-bk-naca.4/include/asm-ppc64/naca.h 2004-12-10 16:26:51.000000000 +1100 +++ linus-bk-naca.5/include/asm-ppc64/naca.h 2004-12-10 18:42:14.000000000 +1100 @@ -11,7 +11,6 @@ */ #include -#include #ifndef __ASSEMBLY__ @@ -20,7 +19,6 @@ void *xItVpdAreas; /* VPD Data 0x00 */ void *xRamDisk; /* iSeries ramdisk 0x08 */ u64 xRamDiskSize; /* In pages 0x10 */ - struct paca_struct *paca; /* Ptr to an array of pacas 0x18 */ u64 debug_switch; /* Debug print control 0x20 */ u64 banner; /* Ptr to banner string 0x28 */ u64 log; /* Ptr to log buffer 0x30 */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041210/3cd105e8/attachment.pgp From sfr at canb.auug.org.au Sat Dec 11 01:05:48 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Sat, 11 Dec 2004 01:05:48 +1100 Subject: [PATCH][RFC] remove serialPortAddr from the naca In-Reply-To: <20041210184837.26a1cddc.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041209155037.666233c8.sfr@canb.auug.org.au> <20041210151547.6c847cb5.sfr@canb.auug.org.au> <20041210160322.1dcb659d.sfr@canb.auug.org.au> <20041210184837.26a1cddc.sfr@canb.auug.org.au> Message-ID: <20041211010548.1a10d459.sfr@canb.auug.org.au> Hi all, This patch just removes serialPortAddr from the naca. This patch has not even been compiled, but seems straight forward. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk-naca.5/arch/ppc64/kernel/maple_setup.c linus-bk-naca.6/arch/ppc64/kernel/maple_setup.c --- linus-bk-naca.5/arch/ppc64/kernel/maple_setup.c 2004-12-10 16:26:51.000000000 +1100 +++ linus-bk-naca.6/arch/ppc64/kernel/maple_setup.c 2004-12-11 00:53:42.000000000 +1100 @@ -75,7 +75,8 @@ extern void maple_pci_init(void); extern void maple_pcibios_fixup(void); extern int maple_pci_get_legacy_ide_irq(struct pci_dev *dev, int channel); -extern void generic_find_legacy_serial_ports(unsigned int *default_speed); +extern void generic_find_legacy_serial_ports(u64 *physport, + unsigned int *default_speed); static void maple_restart(char *cmd) @@ -129,6 +130,7 @@ static void __init maple_init_early(void) { unsigned int default_speed; + u64 physport; DBG(" -> maple_init_early\n"); @@ -138,14 +140,14 @@ hpte_init_native(); /* Find the serial port */ - generic_find_legacy_serial_ports(&default_speed); + generic_find_legacy_serial_ports(&physport, &default_speed); - DBG("naca->serialPortAddr: %lx\n", (long)naca->serialPortAddr); + DBG("phys port addr: %lx\n", (long)physport); - if (naca->serialPortAddr) { + if (physport) { void *comport; /* Map the uart for udbg. */ - comport = (void *)__ioremap(naca->serialPortAddr, 16, _PAGE_NO_CACHE); + comport = (void *)__ioremap(physport, 16, _PAGE_NO_CACHE); udbg_init_uart(comport, default_speed); ppc_md.udbg_putc = udbg_putc; diff -ruN linus-bk-naca.5/arch/ppc64/kernel/pSeries_setup.c linus-bk-naca.6/arch/ppc64/kernel/pSeries_setup.c --- linus-bk-naca.5/arch/ppc64/kernel/pSeries_setup.c 2004-12-10 16:26:51.000000000 +1100 +++ linus-bk-naca.6/arch/ppc64/kernel/pSeries_setup.c 2004-12-11 00:56:42.000000000 +1100 @@ -81,7 +81,8 @@ extern int pSeries_set_rtc_time(struct rtc_time *rtc_time); extern void find_udbg_vterm(void); extern void SystemReset_FWNMI(void), MachineCheck_FWNMI(void); /* from head.S */ -extern void generic_find_legacy_serial_ports(unsigned int *default_speed); +extern void generic_find_legacy_serial_ports(u64 *physport, + unsigned int *default_speed); int fwnmi_active; /* TRUE if an FWNMI handler is present */ @@ -341,6 +342,7 @@ void *comport; int iommu_off = 0; unsigned int default_speed; + u64 physport; DBG(" -> pSeries_init_early()\n"); @@ -354,13 +356,13 @@ get_property(of_chosen, "linux,iommu-off", NULL)); } - generic_find_legacy_serial_ports(&default_speed); + generic_find_legacy_serial_ports(&physport, &default_speed); if (systemcfg->platform & PLATFORM_LPAR) find_udbg_vterm(); - else if (naca->serialPortAddr) { + else if (physport) { /* Map the uart for udbg. */ - comport = (void *)__ioremap(naca->serialPortAddr, 16, _PAGE_NO_CACHE); + comport = (void *)__ioremap(physport, 16, _PAGE_NO_CACHE); udbg_init_uart(comport, default_speed); ppc_md.udbg_putc = udbg_putc; diff -ruN linus-bk-naca.5/arch/ppc64/kernel/setup.c linus-bk-naca.6/arch/ppc64/kernel/setup.c --- linus-bk-naca.5/arch/ppc64/kernel/setup.c 2004-12-10 16:26:51.000000000 +1100 +++ linus-bk-naca.6/arch/ppc64/kernel/setup.c 2004-12-11 00:59:30.000000000 +1100 @@ -1154,7 +1154,8 @@ static struct plat_serial8250_port serial_ports[MAX_LEGACY_SERIAL_PORTS+1]; static unsigned int old_serial_count; -void __init generic_find_legacy_serial_ports(unsigned int *default_speed) +void __init generic_find_legacy_serial_ports(u64 *physport, + unsigned int *default_speed) { struct device_node *np; u32 *sizeprop; @@ -1172,7 +1173,7 @@ DBG(" -> generic_find_legacy_serial_port()\n"); - naca->serialPortAddr = 0; + *physport = 0; if (default_speed) *default_speed = 0; @@ -1294,7 +1295,7 @@ io_base = (io_base << 32) | rangesp[4]; } if (io_base != 0) { - naca->serialPortAddr = io_base + reg->address; + *physport = io_base + reg->address; if (default_speed && spd) *default_speed = *spd; } diff -ruN linus-bk-naca.5/include/asm-ppc64/naca.h linus-bk-naca.6/include/asm-ppc64/naca.h --- linus-bk-naca.5/include/asm-ppc64/naca.h 2004-12-10 18:42:14.000000000 +1100 +++ linus-bk-naca.6/include/asm-ppc64/naca.h 2004-12-11 00:03:55.000000000 +1100 @@ -22,7 +22,6 @@ u64 debug_switch; /* Debug print control 0x20 */ u64 banner; /* Ptr to banner string 0x28 */ u64 log; /* Ptr to log buffer 0x30 */ - u64 serialPortAddr; /* Phy addr of serial port 0x38 */ }; extern struct naca_struct *naca; -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041211/3edfb1a8/attachment.pgp From anton at samba.org Sat Dec 11 04:06:16 2004 From: anton at samba.org (Anton Blanchard) Date: Sat, 11 Dec 2004 04:06:16 +1100 Subject: [PATCH][RFC] remove paca pointer from the naca In-Reply-To: <20041210184837.26a1cddc.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041209155037.666233c8.sfr@canb.auug.org.au> <20041210151547.6c847cb5.sfr@canb.auug.org.au> <20041210160322.1dcb659d.sfr@canb.auug.org.au> <20041210184837.26a1cddc.sfr@canb.auug.org.au> Message-ID: <20041210170616.GD24640@krispykreme.ozlabs.ibm.com> Hi Stephen, > This patch just removes the paca pointer from the naca (and the one > reference to it). It turns out that it was just there so that the > iSeries startup code could find the paca in order to pass a member > of it to iSeries_early_init - which now takes no arguments ... > > Built and booted on iSeries (which is the only thing affected). > Built on pSeries and pmac. Nice! FYI The naca and systemcfg structures are pointers to try and make early boot easier (they relocate the pointer at boot once while we are running at an offset, then again once we have copied down). However this makes things strange (only the boot cpu sees this, the secondary threads get the paca + systemcfg in their final place). We would also save a load if they were structs and not pointers to structs However making these changes would involve a fair amount of churn :( Anton From sfr at canb.auug.org.au Sat Dec 11 11:03:42 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Sat, 11 Dec 2004 11:03:42 +1100 Subject: [PATCH][RFC] naca cleanups: debug_switch, log and banner In-Reply-To: <20041211010548.1a10d459.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041209155037.666233c8.sfr@canb.auug.org.au> <20041210151547.6c847cb5.sfr@canb.auug.org.au> <20041210160322.1dcb659d.sfr@canb.auug.org.au> <20041210184837.26a1cddc.sfr@canb.auug.org.au> <20041211010548.1a10d459.sfr@canb.auug.org.au> Message-ID: <20041211110342.5484b454.sfr@canb.auug.org.au> This patch removes debug_switch, banner and log from the naca (banner and log were unused). Also some cleanups of almost the last references to the naca. Not compiled. Just for comment. -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk-naca.6/arch/ppc64/kernel/pSeries_setup.c linus-bk-naca.7/arch/ppc64/kernel/pSeries_setup.c --- linus-bk-naca.6/arch/ppc64/kernel/pSeries_setup.c 2004-12-11 00:56:42.000000000 +1100 +++ linus-bk-naca.7/arch/ppc64/kernel/pSeries_setup.c 2004-12-11 02:32:17.000000000 +1100 @@ -56,7 +56,6 @@ #include #include #include -#include #include #include @@ -314,7 +313,7 @@ else if (strstr(typep, "ppc-xicp")) ppc64_interrupt_controller = IC_PPC_XIC; else - printk("initialize_naca: failed to recognize" + printk("initialize_cache_info: failed to recognize" " interrupt-controller\n"); break; } diff -ruN linus-bk-naca.6/arch/ppc64/kernel/setup.c linus-bk-naca.7/arch/ppc64/kernel/setup.c --- linus-bk-naca.6/arch/ppc64/kernel/setup.c 2004-12-11 00:59:30.000000000 +1100 +++ linus-bk-naca.7/arch/ppc64/kernel/setup.c 2004-12-11 02:37:18.000000000 +1100 @@ -41,7 +41,6 @@ #include #include #include -#include #include #include #include @@ -113,6 +112,7 @@ int boot_cpuid_phys = 0; dev_t boot_dev; u64 ppc64_pft_size; +u64 ppc64_debug_switch; struct ppc64_caches ppc64_caches; @@ -161,7 +161,7 @@ */ void __init ppcdbg_initialize(void) { - naca->debug_switch = PPC_DEBUG_DEFAULT; /* | PPCDBG_BUSWALK | */ + ppc64_debug_switch = PPC_DEBUG_DEFAULT; /* | PPCDBG_BUSWALK | */ /* PPCDBG_PHBINIT | PPCDBG_MM | PPCDBG_MMINIT | PPCDBG_TCEINIT | PPCDBG_TCE */; } @@ -399,7 +399,7 @@ DBG(" -> early_setup()\n"); /* - * Fill the default DBG level in naca (do we want to keep + * Fill the default DBG level (do we want to keep * that old mecanism around forever ?) */ ppcdbg_initialize(); @@ -453,17 +453,17 @@ /* - * Initialize some remaining members of the naca and systemcfg structures + * Initialize some remaining members of the ppc64_caches and systemcfg structures * (at least until we get rid of them completely). This is mostly some * cache informations about the CPU that will be used by cache flush * routines and/or provided to userland */ -static void __init initialize_naca(void) +static void __init initialize_cache_info(void) { struct device_node *np; unsigned long num_cpus = 0; - DBG(" -> initialize_naca()\n"); + DBG(" -> initialize_cache_info()\n"); for (np = NULL; (np = of_find_node_by_type(np, "cpu"));) { num_cpus += 1; @@ -530,7 +530,7 @@ systemcfg->version.minor = SYSTEMCFG_MINOR; systemcfg->processor = mfspr(SPRN_PVR); - DBG(" <- initialize_naca()\n"); + DBG(" <- initialize_cache_info()\n"); } static void __init check_for_initrd(void) @@ -591,7 +591,7 @@ unflatten_device_tree(); /* - * Fill the naca & systemcfg structures with informations + * Fill the ppc64_caches & systemcfg structures with informations * retreived from the device-tree. Need to be called before * finish_device_tree() since the later requires some of the * informations filled up here to properly parse the interrupt @@ -600,7 +600,7 @@ * routines like flush_icache_range (used by the hash init * later on). */ - initialize_naca(); + initialize_cache_info(); #ifdef CONFIG_PPC_PSERIES /* @@ -661,9 +661,8 @@ printk("Starting Linux PPC64 %s\n", UTS_RELEASE); printk("-----------------------------------------------------\n"); - printk("naca = 0x%p\n", naca); printk("ppc64_pft_size = 0x%lx\n", ppc64_pft_size); - printk("naca->debug_switch = 0x%lx\n", naca->debug_switch); + printk("ppc64_debug_switch = 0x%lx\n", ppc64_debug_switch); printk("ppc64_interrupt_controller = 0x%ld\n", ppc64_interrupt_controller); printk("systemcfg = 0x%p\n", systemcfg); printk("systemcfg->platform = 0x%x\n", systemcfg->platform); diff -ruN linus-bk-naca.6/arch/ppc64/kernel/udbg.c linus-bk-naca.7/arch/ppc64/kernel/udbg.c --- linus-bk-naca.6/arch/ppc64/kernel/udbg.c 2004-11-22 14:05:02.000000000 +1100 +++ linus-bk-naca.7/arch/ppc64/kernel/udbg.c 2004-12-11 02:31:17.000000000 +1100 @@ -15,7 +15,6 @@ #include #include #include -#include #include #include #include @@ -323,7 +322,7 @@ /* Special print used by PPCDBG() macro */ void udbg_ppcdbg(unsigned long debug_flags, const char *fmt, ...) { - unsigned long active_debugs = debug_flags & naca->debug_switch; + unsigned long active_debugs = debug_flags & ppc64_debug_switch; if (active_debugs) { va_list ap; @@ -357,5 +356,5 @@ unsigned long udbg_ifdebug(unsigned long flags) { - return (flags & naca->debug_switch); + return (flags & ppc64_debug_switch); } diff -ruN linus-bk-naca.6/arch/ppc64/xmon/xmon.c linus-bk-naca.7/arch/ppc64/xmon/xmon.c --- linus-bk-naca.6/arch/ppc64/xmon/xmon.c 2004-11-26 12:08:51.000000000 +1100 +++ linus-bk-naca.7/arch/ppc64/xmon/xmon.c 2004-12-11 02:33:00.000000000 +1100 @@ -26,7 +26,6 @@ #include #include #include -#include #include #include #include @@ -2360,9 +2359,9 @@ if (cmd == '\n') { /* show current state */ unsigned long i; - printf("naca->debug_switch = 0x%lx\n", naca->debug_switch); + printf("ppc64_debug_switch = 0x%lx\n", ppc64_debug_switch); for (i = 0; i < PPCDBG_NUM_FLAGS ;i++) { - on = PPCDBG_BITVAL(i) & naca->debug_switch; + on = PPCDBG_BITVAL(i) & ppc64_debug_switch; printf("%02x %s %12s ", i, on ? "on " : "off", trace_names[i] ? trace_names[i] : ""); if (((i+1) % 3) == 0) printf("\n"); @@ -2376,7 +2375,7 @@ on = (cmd == '+'); cmd = inchar(); if (cmd == ' ' || cmd == '\n') { /* Turn on or off based on + or - */ - naca->debug_switch = on ? PPCDBG_ALL:PPCDBG_NONE; + ppc64_debug_switch = on ? PPCDBG_ALL:PPCDBG_NONE; printf("Setting all values to %s...\n", on ? "on" : "off"); if (cmd == '\n') return; else cmd = skipbl(); @@ -2391,10 +2390,10 @@ return; } if (on) { - naca->debug_switch |= PPCDBG_BITVAL(val); + ppc64_debug_switch |= PPCDBG_BITVAL(val); printf("enable debug %x %s\n", val, trace_names[val] ? trace_names[val] : ""); } else { - naca->debug_switch &= ~PPCDBG_BITVAL(val); + ppc64_debug_switch &= ~PPCDBG_BITVAL(val); printf("disable debug %x %s\n", val, trace_names[val] ? trace_names[val] : ""); } cmd = skipbl(); diff -ruN linus-bk-naca.6/include/asm-ppc64/naca.h linus-bk-naca.7/include/asm-ppc64/naca.h --- linus-bk-naca.6/include/asm-ppc64/naca.h 2004-12-11 00:03:55.000000000 +1100 +++ linus-bk-naca.7/include/asm-ppc64/naca.h 2004-12-11 02:41:18.000000000 +1100 @@ -19,9 +19,6 @@ void *xItVpdAreas; /* VPD Data 0x00 */ void *xRamDisk; /* iSeries ramdisk 0x08 */ u64 xRamDiskSize; /* In pages 0x10 */ - u64 debug_switch; /* Debug print control 0x20 */ - u64 banner; /* Ptr to banner string 0x28 */ - u64 log; /* Ptr to log buffer 0x30 */ }; extern struct naca_struct *naca; diff -ruN linus-bk-naca.6/include/asm-ppc64/ppcdebug.h linus-bk-naca.7/include/asm-ppc64/ppcdebug.h --- linus-bk-naca.6/include/asm-ppc64/ppcdebug.h 2004-02-16 08:19:48.000000000 +1100 +++ linus-bk-naca.7/include/asm-ppc64/ppcdebug.h 2004-12-11 02:35:37.000000000 +1100 @@ -22,7 +22,7 @@ #define PPCDBG_BITVAL(X) ((1UL)<<((unsigned long)(X))) /* Defined below are the bit positions of various debug flags in the - * debug_switch variable (defined in naca.h). + * ppc64_debug_switch variable. * -- When adding new values, please enter them into trace names below -- * * Values 62 & 63 can be used to stress the hardware page table management @@ -64,6 +64,8 @@ #define PPCDBG_NUM_FLAGS 64 +extern u64 ppc64_debug_switch; + #ifdef WANT_PPCDBG_TAB /* A table of debug switch names to allow name lookup in xmon * (and whoever else wants it. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041211/32a2d63d/attachment.pgp From sfr at canb.auug.org.au Sat Dec 11 11:07:23 2004 From: sfr at canb.auug.org.au (Stephen Rothwell) Date: Sat, 11 Dec 2004 11:07:23 +1100 Subject: [PATCH][RFC] naca cleanups: naca becomes a struct In-Reply-To: <20041211110342.5484b454.sfr@canb.auug.org.au> References: <20041209003800.7e38a32c.sfr@canb.auug.org.au> <20041209155037.666233c8.sfr@canb.auug.org.au> <20041210151547.6c847cb5.sfr@canb.auug.org.au> <20041210160322.1dcb659d.sfr@canb.auug.org.au> <20041210184837.26a1cddc.sfr@canb.auug.org.au> <20041211010548.1a10d459.sfr@canb.auug.org.au> <20041211110342.5484b454.sfr@canb.auug.org.au> Message-ID: <20041211110723.5e4f239f.sfr@canb.auug.org.au> Last naca cleanup: the naca is now a struct instead of a pointer and no longer appears except for iSeries. Not even compiled. Just for comment. (Anton: I guess I should have sent this last night! :-)) -- Cheers, Stephen Rothwell sfr at canb.auug.org.au http://www.canb.auug.org.au/~sfr/ diff -ruN linus-bk-naca.7/arch/ppc64/kernel/LparData.c linus-bk-naca.8/arch/ppc64/kernel/LparData.c --- linus-bk-naca.7/arch/ppc64/kernel/LparData.c 2004-10-26 16:06:41.000000000 +1000 +++ linus-bk-naca.8/arch/ppc64/kernel/LparData.c 2004-12-11 02:49:48.000000000 +1100 @@ -44,7 +44,7 @@ 0xc8a5d9c4, /* desc = "HvRD" ebcdic */ sizeof(struct HvReleaseData), offsetof(struct naca_struct, xItVpdAreas), - (struct naca_struct *)(NACA_VIRT_ADDR), /* 64-bit Naca address */ + &naca, /* 64-bit Naca address */ 0x6000, /* offset of LparMap within loadarea (see head.S) */ 0, 1, /* tags inactive */ diff -ruN linus-bk-naca.7/arch/ppc64/kernel/head.S linus-bk-naca.8/arch/ppc64/kernel/head.S --- linus-bk-naca.7/arch/ppc64/kernel/head.S 2004-12-10 18:40:24.000000000 +1100 +++ linus-bk-naca.8/arch/ppc64/kernel/head.S 2004-12-11 02:56:12.000000000 +1100 @@ -512,17 +512,15 @@ */ . = NACA_PHYS_ADDR .globl __end_interrupts - .globl __start_naca __end_interrupts: -__start_naca: #ifdef CONFIG_PPC_ISERIES + .globl naca +naca: .llong itVpdAreas #endif . = SYSTEMCFG_PHYS_ADDR - .globl __end_naca .globl __start_systemcfg -__end_naca: __start_systemcfg: . = (SYSTEMCFG_PHYS_ADDR + PAGE_SIZE) .globl __end_systemcfg @@ -1270,10 +1268,6 @@ SET_REG_TO_CONST(r4, SYSTEMCFG_VIRT_ADDR) std r4,0(r9) /* set the systemcfg pointer */ - LOADADDR(r9,naca) - SET_REG_TO_CONST(r4, NACA_VIRT_ADDR) - std r4,0(r9) /* set the naca pointer */ - bl .iSeries_early_setup /* relocation is on at this point */ @@ -1873,12 +1867,6 @@ li r27,SYSTEMCFG_PHYS_ADDR std r27,0(r6) /* set the value of systemcfg */ - /* setup the naca pointer which is needed by *tab_initialize */ - LOADADDR(r6,naca) - sub r6,r6,r26 /* addr of the variable naca */ - li r27,NACA_PHYS_ADDR - std r27,0(r6) /* set the value of naca */ - #ifdef CONFIG_HMT /* Start up the second thread on cpu 0 */ mfspr r3,PVR @@ -2015,11 +2003,6 @@ SET_REG_TO_CONST(r8, SYSTEMCFG_VIRT_ADDR) std r8,0(r9) - /* setup the naca pointer */ - LOADADDR(r9,naca) - SET_REG_TO_CONST(r8, NACA_VIRT_ADDR) - std r8,0(r9) /* set the value of the naca ptr */ - LOADADDR(r26, boot_cpuid) lwz r26,0(r26) diff -ruN linus-bk-naca.7/arch/ppc64/kernel/iSeries_setup.c linus-bk-naca.8/arch/ppc64/kernel/iSeries_setup.c --- linus-bk-naca.7/arch/ppc64/kernel/iSeries_setup.c 2004-12-10 16:26:44.000000000 +1100 +++ linus-bk-naca.8/arch/ppc64/kernel/iSeries_setup.c 2004-12-11 02:51:17.000000000 +1100 @@ -314,13 +314,13 @@ * If the init RAM disk has been configured and there is * a non-zero starting address for it, set it up */ - if (naca->xRamDisk) { - initrd_start = (unsigned long)__va(naca->xRamDisk); - initrd_end = initrd_start + naca->xRamDiskSize * PAGE_SIZE; + if (naca.xRamDisk) { + initrd_start = (unsigned long)__va(naca.xRamDisk); + initrd_end = initrd_start + naca.xRamDiskSize * PAGE_SIZE; initrd_below_start_ok = 1; // ramdisk in kernel space ROOT_DEV = Root_RAM0; - if (((rd_size * 1024) / PAGE_SIZE) < naca->xRamDiskSize) - rd_size = (naca->xRamDiskSize * PAGE_SIZE) / 1024; + if (((rd_size * 1024) / PAGE_SIZE) < naca.xRamDiskSize) + rd_size = (naca.xRamDiskSize * PAGE_SIZE) / 1024; } else #endif /* CONFIG_BLK_DEV_INITRD */ { @@ -813,9 +813,9 @@ * Change klimit to take into account any ram disk * that may be included */ - if (naca->xRamDisk) - klimit = KERNELBASE + (u64)naca->xRamDisk + - (naca->xRamDiskSize * PAGE_SIZE); + if (naca.xRamDisk) + klimit = KERNELBASE + (u64)naca.xRamDisk + + (naca.xRamDiskSize * PAGE_SIZE); else { /* * No ram disk was included - check and see if there diff -ruN linus-bk-naca.7/arch/ppc64/kernel/pacaData.c linus-bk-naca.8/arch/ppc64/kernel/pacaData.c --- linus-bk-naca.7/arch/ppc64/kernel/pacaData.c 2004-12-10 16:26:44.000000000 +1100 +++ linus-bk-naca.8/arch/ppc64/kernel/pacaData.c 2004-12-11 02:50:23.000000000 +1100 @@ -18,11 +18,8 @@ #include #include -#include #include -struct naca_struct *naca; -EXPORT_SYMBOL(naca); struct systemcfg *systemcfg; EXPORT_SYMBOL(systemcfg); diff -ruN linus-bk-naca.7/include/asm-ppc64/iSeries/HvReleaseData.h linus-bk-naca.8/include/asm-ppc64/iSeries/HvReleaseData.h --- linus-bk-naca.7/include/asm-ppc64/iSeries/HvReleaseData.h 2004-01-20 08:20:26.000000000 +1100 +++ linus-bk-naca.8/include/asm-ppc64/iSeries/HvReleaseData.h 2004-12-11 02:52:05.000000000 +1100 @@ -26,6 +26,7 @@ // address of the OS's NACA). // #include +#include //============================================================================= // diff -ruN linus-bk-naca.7/include/asm-ppc64/naca.h linus-bk-naca.8/include/asm-ppc64/naca.h --- linus-bk-naca.7/include/asm-ppc64/naca.h 2004-12-11 02:41:18.000000000 +1100 +++ linus-bk-naca.8/include/asm-ppc64/naca.h 2004-12-11 02:54:02.000000000 +1100 @@ -21,12 +21,11 @@ u64 xRamDiskSize; /* In pages 0x10 */ }; -extern struct naca_struct *naca; +extern struct naca_struct naca; #endif /* __ASSEMBLY__ */ #define NACA_PAGE 0x4 #define NACA_PHYS_ADDR (NACA_PAGE< References: Message-ID: <8285758A-4C70-11D9-B290-000A95D7C5AE@csbl.bmb.uga.edu> You should be able to build a ppc64 kernel from standard kernel sources. I was able to successfully compile the 2.6.9 kernel (no patches) for a XServe 2.0GHz G5. Previous kernels crashed on boot up for this machine. I did this using a standard copy of YDL 4.0 (I haven't tried from 3.0.1, but should be pretty much the same assuming it's got a G5 capable copy of yaboot), and cross tool (http://kegel.com/crosstool/) Once you've gotten cross tool, run demo_ppc970.sh and add the created tool chain bin to your PATH Then you can build the kernel with make ARCH=ppc64 CROSS_COMPILE=powerpc64-unknown-linux-gnu- Remember to copy in arch/ppc64/configs/g5_defconfig to .config in the kernel source directory. Kyle > Hi, > > Is the source code for Y-HPC (Yellow Dog Linux version 3.0.1 from > Terrasoft) available? Where can I get them? > > Amit K T > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/cgi-bin/mailman/listinfo/linuxppc64-dev From l_indien at magic.fr Mon Dec 13 07:02:24 2004 From: l_indien at magic.fr (J. Mayer) Date: Sun, 12 Dec 2004 21:02:24 +0100 Subject: Patch for Imac G5. Message-ID: <1102881744.9705.30840.camel@rapid> Hi, I updated the patchset for Imac G5 in order to use linux-2.6.10_rc3. I noticed that the machine even does not boot if I don't apply the PCI initialisation workaround. I did change some things in my code so that SMU & PMU can now be compiled together. I also did build a kernel, which is the one I currently used, as some people requested for a precompiled kernel and/or valid configuration file. Here you'll find all those stuffs: Regards. -- J. Mayer Never organized From ostampflee at terrasoftsolutions.com Mon Dec 13 08:59:11 2004 From: ostampflee at terrasoftsolutions.com (Owen Stampflee) Date: Sun, 12 Dec 2004 13:59:11 -0800 Subject: Y-HPC Source Code In-Reply-To: <8285758A-4C70-11D9-B290-000A95D7C5AE@csbl.bmb.uga.edu> References: <8285758A-4C70-11D9-B290-000A95D7C5AE@csbl.bmb.uga.edu> Message-ID: <1102888751.4812.174.camel@beast.terraplex.com> Y-HPC source code (minus the installer and Y-Imager) is available to those who purchase Y-HPC. Cheers, Owen From paulus at samba.org Mon Dec 13 15:10:27 2004 From: paulus at samba.org (Paul Mackerras) Date: Mon, 13 Dec 2004 15:10:27 +1100 Subject: Some ppc64 signal/ptrace patches. In-Reply-To: <1101478729.8191.9543.camel@hades.cambridge.redhat.com> References: <1101478729.8191.9543.camel@hades.cambridge.redhat.com> Message-ID: <16829.5683.920523.687438@cargo.ozlabs.ibm.com> David Woodhouse writes: > First, single-stepping into and out of signals wasn't working. We were > sending a SIGTRAP to the debugger on the second instruction of the > handler, not the first. The patch you included doesn't seem to have the bits to fix that. > Second, the return path from sigsuspend() was stomping on the r4 and r5 > registers (the args to the signal handler) by using syscall_exit to get > back to userspace instead of ret_from_except. Likewise, there were no entry.S changes in the patch. Care to send an all-inclusive patch, or series of patches, that fix all these problems? > Third, signals were remaining masked when a signal handler was _NOT_ > invoked due to having a bogus altstack. We aborted the setup of the > signal frame and forced a SIGSEGV, but we didn't put the original signal > mask back. As discovered by Bodo Stroesser. AFAICS we will now just stay in the loop in sys_[32][rt_]sigsuspend in this case, rather than actually ever delivering the SIGSEGV... Paul. From paulus at samba.org Mon Dec 13 16:22:12 2004 From: paulus at samba.org (Paul Mackerras) Date: Mon, 13 Dec 2004 16:22:12 +1100 Subject: [PATCH] PPC64: EEH Recovery In-Reply-To: <20041123185916.GJ23780@austin.ibm.com> References: <015EEEE2-3D09-11D9-8147-003065DC03B0@bga.com> <20041123185916.GJ23780@austin.ibm.com> Message-ID: <16829.9988.718077.16580@cargo.ozlabs.ibm.com> Linas Vepstas writes: > No not at all. As I said, all I really wanted to do was to save the > bars. I actually thought about saving the bars in the device_node, > but I then anticipated that some wise-guy on this mailing list suggest > that I save the bars in the pci_dev instead. So I saved the bars > in pci_dev instead. I did *not* anticipate your comments. Saving the BARs in the pci_dev does indeed seem like the right thing. Milton, why did you prefer to put them in the device_node? In general I would like to unload the PCI-related stuff from the device_node. We probably need a per-PCI-device struct for the various ppc64-specific things we need to record for each PCI device. Linas, this part of the patch: @@ -223,9 +220,9 @@ pci_addr_cache_insert(struct pci_dev *de while (*p) { parent = *p; piar = rb_entry(parent, struct pci_io_addr_range, rb_node); - if (alo < piar->addr_lo) { + if (ahi < piar->addr_lo) { p = &parent->rb_left; - } else if (ahi > piar->addr_hi) { + } else if (alo > piar->addr_hi) { p = &parent->rb_right; } else { if (dev != piar->pcidev || looks like a bug fix, unrelated to the other changes you are making. Is that the case? Could you explain what is being fixed and why? Paul. From linas at austin.ibm.com Tue Dec 14 06:17:55 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Mon, 13 Dec 2004 13:17:55 -0600 Subject: [PATCH] PPC64: EEH Recovery In-Reply-To: <16829.9988.718077.16580@cargo.ozlabs.ibm.com> References: <015EEEE2-3D09-11D9-8147-003065DC03B0@bga.com> <20041123185916.GJ23780@austin.ibm.com> <16829.9988.718077.16580@cargo.ozlabs.ibm.com> Message-ID: <20041213191755.GN22600@austin.ibm.com> On Mon, Dec 13, 2004 at 04:22:12PM +1100, Paul Mackerras was heard to remark: > Linas Vepstas writes: > > > No not at all. As I said, all I really wanted to do was to save the > > bars. I actually thought about saving the bars in the device_node, > > but I then anticipated that some wise-guy on this mailing list suggest > > that I save the bars in the pci_dev instead. So I saved the bars > > in pci_dev instead. I did *not* anticipate your comments. > > Saving the BARs in the pci_dev does indeed seem like the right thing. > Milton, why did you prefer to put them in the device_node? I can't speak for Milton, but I can offer up one reason. When the pci device is removed, the pci_device struct is freed (and if it has bridges/multi-function, then a tree of pci_device struct). So, in order to be able to access data in the struct, after the device delete, I was doing something funky: doing a pci_get to make sure the struct wasn't freed until I was done with it. Of course, the device_node is freed as well, so I have to dn_get to make sure it doesn't disappear from under me. But at least this way, I have to get only one set of objects, not two, and so this does reduce total complexity slightly. > Linas, this part of the patch: > > @@ -223,9 +220,9 @@ pci_addr_cache_insert(struct pci_dev *de > while (*p) { > parent = *p; > piar = rb_entry(parent, struct pci_io_addr_range, rb_node); > - if (alo < piar->addr_lo) { > + if (ahi < piar->addr_lo) { > p = &parent->rb_left; > - } else if (ahi > piar->addr_hi) { > + } else if (alo > piar->addr_hi) { > p = &parent->rb_right; > } else { > if (dev != piar->pcidev || > > looks like a bug fix, unrelated to the other changes you are making. > Is that the case? Not really. If the pci subsystem is working correctly, this change has no effect. It only makes a differece if PCI addresses were assigned incorrectly, in which case, the updated code will catch that error. > Could you explain what is being fixed and why? The "pci address cache" is a collection of address ranges that can be used to find the pci device associated with a given address. In a "correctly working system", these adress ranges are non-overlapping. (an i/o address can be associated to only one pci dev.) To be able to find a device quickly, I hold the address ranges in sorted order. The above code is merely trying to find the insertion point for a new address range. As long as the ranges are non-overlapping, I can sort by comparing bottom-of-range to bottom-of-range, or by comparing top-of-previous to bottom-of-next, or comparing midpoints, etc. Any of these will work. But if the address ranges overlap, the old code won't notice it, whereas the patched code will, and print a warning. i.e. in order to not overlap, the highest address of one range must be less than the lowest address of the next range. Since sometimes programmers introduce errors in assigning pci addresses, the patch will help rpovide an early warning for one type of error. --linas From linas at austin.ibm.com Tue Dec 14 08:37:45 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Mon, 13 Dec 2004 15:37:45 -0600 Subject: [PATCH] PPC64: Recursive xmon call due to bad stack Message-ID: <20041213213745.GO22600@austin.ibm.com> Hi, I had a recursive call to xmon in linux-2.6.10-rc2 after a crash to firmware. I beleive the patch below should fix this, although I was not able to test it, cause I can't reproduce the crash. Based on what I can tell about how xmon works, I *think* this patch should fix the recursion. Please apply if it looks reasonable. --linas Signed-off-by: Linas Vepstas --- arch/ppc64/xmon/xmon.c.modified 2004-11-19 14:33:50.000000000 -0600 +++ arch/ppc64/xmon/xmon.c 2004-12-13 15:30:49.000000000 -0600 @@ -349,6 +349,17 @@ int xmon_core(struct pt_regs *regs, int printf("cpu 0x%x: Exception %lx %s in xmon, " "returning to main loop\n", cpu, regs->trap, getvecname(TRAP(regs))); + + /* If crash occured in firmware, then saved stack pointer + * is bad, and we get recursive fault. Switch to using + * emergency stack in this case. + */ + unsigned long *sp = ((unsigned long *) xmon_fault_jmp[cpu]) + 1; + if (*sp < 0xc000000000000000) + { + printf("Bad stack %lx in xmon, using emergency stack\n", *sp); + *sp = (unsigned long ) (get_paca()->emergency_sp); + } longjmp(xmon_fault_jmp[cpu], 1); } p.s. Here's the output I saw (before it scrolled off the screen, thank goodness for slow serial lines!) Note msr, pc and lr: crash was in firmware. cpu 0x3: Vector: 700 (Program Check) at [c00000005c8838c0] pc: 00000000077d9374 lr: 000000000000ddf8 sp: c00000005c883b40 msr: 81002 current = 0xc000000055304030 paca = 0xc00000000052b680 pid = 12148, comm = errinjct cpu 0x3: Vector: 700 (Program Check) at [c00000005c882e20] pc: 00000000077d9374 lr: 000000000000ddf8 sp: c00000005c8830a0 msr: 81002 current = 0xc000000055304030 paca = 0xc00000000052b680 pid = 12148, comm = errinjct cpu 0x3: Exception 700 (Program Check) in xmon, returning to main loop Bad kernel stack pointer 22022424 at c00000000004c1fc cpu 0x3: Vector: 0 at [c0000000077c5d40] pc: c00000000004c1fc: .xmon_longjmp+0x84/0x8c lr: c00000000004a1f0: .xmon_core+0xfc/0x848 sp: 22022424 msr: 8000000000001032 current = 0xc000000055304030 paca = 0xc00000000052b680 pid = 12148, comm = errinjct cpu 0x3: Exception 0 in xmon, returning to main loop Bad kernel stack pointer 22022424 at c00000000004c1fc cpu 0x3: Vector: 0 at [c0000000077c5d40] pc: c00000000004c1fc: .xmon_longjmp+0x84/0x8c lr: c00000000004a1f0: .xmon_core+0xfc/0x848 sp: 22022424 msr: 8000000000001032 current = 0xc000000055304030 paca = 0xc00000000052b680 pid = 12148, comm = errinjct cpu 0x3: Exception 0 in xmon, returning to main loop Bad kernel stack pointer 22022424 at c00000000004c1fc cpu 0x3: Vector: 0 at [c0000000077c5d40] pc: c00000000004c1fc: .xmon_longjmp+0x84/0x8c lr: c00000000004a1f0: .xmon_core+0xfc/0x848 and etc repeating after here. From linas at austin.ibm.com Wed Dec 15 08:22:12 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Tue, 14 Dec 2004 15:22:12 -0600 Subject: [PATCH} PPC64: revised patch for recursive xmon entry Message-ID: <20041214212212.GA12627@austin.ibm.com> Hi, I had a recursive call to xmon in linux-2.6.10-rc2 after a crash to firmware. The resursion was due to a scrambled value in r1 inherited from firmware. The following patch prevents the recursion and sets up a usable stack. Unfortunately, it still doesn't get us to an xmon prompt; xmon thinks some other cpu is in control. I'll see if I can fix that next, if I manage to reproduce. This patch obsoletes the one I sent yesterday. --linas Signed-off-by: Linas Vepstas --- arch/ppc64/xmon/xmon.c.modified 2004-11-19 14:33:50.000000000 -0600 +++ arch/ppc64/xmon/xmon.c 2004-12-14 15:13:06.000000000 -0600 @@ -349,6 +349,25 @@ int xmon_core(struct pt_regs *regs, int printf("cpu 0x%x: Exception %lx %s in xmon, " "returning to main loop\n", cpu, regs->trap, getvecname(TRAP(regs))); + + /* If crash occured in firmware, then saved stack pointer + * is bad, and we get recursive fault. Switch to using + * emergency stack in this case. + */ + unsigned long *sp = ((unsigned long *) xmon_fault_jmp[cpu]) + 1; + if (*sp < 0xc000000000000000) + { + printf("Bad stack pointer %lx in xmon, using emergency stack\n", *sp); + *sp = (unsigned long ) (get_paca()->emergency_sp); + sp = (unsigned long *) *sp; + *sp = (unsigned long ) (get_paca()->emergency_sp); + } + sp = (unsigned long *) *sp; + if (*sp < 0xc000000000000000) + { + printf("Bad stack frame %lx in xmon, using emergency stack\n", *sp); + *sp = (unsigned long ) (get_paca()->emergency_sp); + } longjmp(xmon_fault_jmp[cpu], 1); } From paulus at samba.org Wed Dec 15 10:54:20 2004 From: paulus at samba.org (Paul Mackerras) Date: Wed, 15 Dec 2004 10:54:20 +1100 Subject: [PATCH} PPC64: revised patch for recursive xmon entry In-Reply-To: <20041214212212.GA12627@austin.ibm.com> References: <20041214212212.GA12627@austin.ibm.com> Message-ID: <16831.32044.423995.328938@cargo.ozlabs.ibm.com> Linas Vepstas writes: > I had a recursive call to xmon in linux-2.6.10-rc2 after a crash > to firmware. The resursion was due to a scrambled value in r1 > inherited from firmware. The following patch prevents the recursion > and sets up a usable stack. Unfortunately, it still doesn't get us > to an xmon prompt; xmon thinks some other cpu is in control. > I'll see if I can fix that next, if I manage to reproduce. I don't think this is the right approach; we should be detecting the bogus stack pointer and switching to the emergency stack in the exception entry code. By the time we get to your stack we would have already been using the bogus stack for some time. Paul. From linas at austin.ibm.com Wed Dec 15 12:20:04 2004 From: linas at austin.ibm.com (Linas Vepstas) Date: Tue, 14 Dec 2004 19:20:04 -0600 Subject: [PATCH} PPC64: revised patch for recursive xmon entry In-Reply-To: <16831.32044.423995.328938@cargo.ozlabs.ibm.com> References: <20041214212212.GA12627@austin.ibm.com> <16831.32044.423995.328938@cargo.ozlabs.ibm.com> Message-ID: <20041215012004.GB12627@austin.ibm.com> On Wed, Dec 15, 2004 at 10:54:20AM +1100, Paul Mackerras was heard to remark: > Linas Vepstas writes: > > > I had a recursive call to xmon in linux-2.6.10-rc2 after a crash > > to firmware. The resursion was due to a scrambled value in r1 > > inherited from firmware. The following patch prevents the recursion > > and sets up a usable stack. Unfortunately, it still doesn't get us > > to an xmon prompt; xmon thinks some other cpu is in control. > > I'll see if I can fix that next, if I manage to reproduce. > > I don't think this is the right approach; we should be detecting the > bogus stack pointer and switching to the emergency stack in the > exception entry code. By the time we get to your stack we would have > already been using the bogus stack for some time. Yes. I concluded something like that once I started actually reading the code I was fixing :, This reproduces every third try (somethings racing somehwere), so I'll know more tommorrow. --linas From moilanen at austin.ibm.com Fri Dec 17 08:39:00 2004 From: moilanen at austin.ibm.com (Jake Moilanen) Date: Thu, 16 Dec 2004 15:39:00 -0600 Subject: [PATCH 0/3] Traps/Head naming cleanup and log machine checks Message-ID: <20041216153900.6b2f87e2@localhost> These patches cleanup traps.c, head.S and adds support for logging machine checks. They mostly clean up the naming convention to more closely resemble the Linux style. I have built for pSeries, iSeries, and PMAC. I have not boot tested an iSeries and Olof is going to boot test a G5 for me. trap-cleanup: Cleans up naming and moves machine dependent calls to a ppc_md. It also moves the pSeries code to a pSeries file. head-cleanup: Cleans up naming conventions. machine-check-logging: Originally from Dave Altobelli, it adds support for machine-check error logs. Thanks, Jake From moilanen at austin.ibm.com Fri Dec 17 08:44:19 2004 From: moilanen at austin.ibm.com (Jake Moilanen) Date: Thu, 16 Dec 2004 15:44:19 -0600 Subject: [PATCH 3/3] machine-check-logging In-Reply-To: <20041216153900.6b2f87e2@localhost> References: <20041216153900.6b2f87e2@localhost> Message-ID: <20041216154419.7d2ffbf2@localhost> Log machine check errors to error log and NVRAM. Signed-off-by: Dave Altobelli Signed-off-by: Jake Moilanen --- diff -puN arch/ppc64/kernel/ras.c~machine-check-logging arch/ppc64/kernel/ras.c --- linux-2.6-bk/arch/ppc64/kernel/ras.c~machine-check-logging Wed Dec 15 15:46:42 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/ras.c Wed Dec 15 15:52:46 2004 @@ -55,9 +55,13 @@ static unsigned char ras_log_buf[RTAS_ERROR_LOG_MAX]; static spinlock_t ras_log_buf_lock = SPIN_LOCK_UNLOCKED; +char mce_data_buf[RTAS_ERROR_LOG_MAX] +; /* This is true if we are using the firmware NMI handler (typically LPAR) */ extern int fwnmi_active; +extern void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr); + static int ras_get_sensor_state_token; static int ras_check_exception_token; @@ -242,6 +246,13 @@ ras_error_interrupt(int irq, void *dev_i * FWNMI vectors. The pt_regs' r3 will be updated to reflect * the actual r3 if possible, and a ptr to the error log entry * will be returned if found. + * + * The mce_data_buf does not have any locks or protection around it, + * if a second machine check comes in, or a system reset is done + * before we have logged the error, then we will get corruption in the + * error log. This is preferable over holding off on calling + * ibm,nmi-interlock which would result in us checkstopping if a + * second machine check did come in. */ static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs) { @@ -253,7 +264,9 @@ static struct rtas_error_log *fwnmi_get_ (errdata >= rtas.base && errdata < rtas.base + rtas.size - 16)) { savep = __va(errdata); regs->gpr[3] = savep[0]; /* restore original r3 */ - errhdr = (struct rtas_error_log *)(savep + 1); + memset(mce_data_buf, 0, RTAS_ERROR_LOG_MAX); + memcpy(mce_data_buf, (char *)(savep + 1), RTAS_ERROR_LOG_MAX); + errhdr = (struct rtas_error_log *)mce_data_buf; } else { printk("FWNMI: corrupt r3\n"); } @@ -291,26 +304,31 @@ void pSeries_system_reset_exception(stru * Return 1 if corrected (or delivered a signal). * Return 0 if there is nothing we can do. */ -static int recover_mce(struct pt_regs *regs, struct rtas_error_log err) +static int recover_mce(struct pt_regs *regs, struct rtas_error_log * err) { - if (err.disposition == RTAS_DISP_FULLY_RECOVERED) { + int nonfatal = 0; + + if (err->disposition == RTAS_DISP_FULLY_RECOVERED) { /* Platform corrected itself */ - return 1; + nonfatal = 1; } else if ((regs->msr & MSR_RI) && user_mode(regs) && - err.severity == RTAS_SEVERITY_ERROR_SYNC && - err.disposition == RTAS_DISP_NOT_RECOVERED && - err.target == RTAS_TARGET_MEMORY && - err.type == RTAS_TYPE_ECC_UNCORR && + err->severity == RTAS_SEVERITY_ERROR_SYNC && + err->disposition == RTAS_DISP_NOT_RECOVERED && + err->target == RTAS_TARGET_MEMORY && + err->type == RTAS_TYPE_ECC_UNCORR && !(current->pid == 0 || current->pid == 1)) { /* Kill off a user process with an ECC error */ printk(KERN_ERR "MCE: uncorrectable ecc error for pid %d\n", current->pid); /* XXX something better for ECC error? */ _exception(SIGBUS, regs, BUS_ADRERR, regs->nip); - return 1; + nonfatal = 1; } - return 0; + + log_error((char *)err, ERR_TYPE_RTAS_LOG, !nonfatal); + + return nonfatal; } /* @@ -325,14 +343,12 @@ static int recover_mce(struct pt_regs *r */ int pSeries_machine_check_exception(struct pt_regs *regs) { - struct rtas_error_log err, *errp; + struct rtas_error_log *errp; if (fwnmi_active) { errp = fwnmi_get_errinfo(regs); - if (errp) - err = *errp; - fwnmi_release_errinfo(); /* frees errp */ - if (errp && recover_mce(regs, err)) + fwnmi_release_errinfo(); + if (errp && recover_mce(regs, errp)) return 1; } _ From moilanen at austin.ibm.com Fri Dec 17 08:42:43 2004 From: moilanen at austin.ibm.com (Jake Moilanen) Date: Thu, 16 Dec 2004 15:42:43 -0600 Subject: [PATCH 2/3] head-cleanup In-Reply-To: <20041216153900.6b2f87e2@localhost> References: <20041216153900.6b2f87e2@localhost> Message-ID: <20041216154243.183e51d8@localhost> Changed the naming conventions for head.S to more closely follow the Linux naming conventions. Signed-off-by: Jake Moilanen --- diff -puN arch/ppc64/kernel/head.S~head_cleanup arch/ppc64/kernel/head.S --- linux-2.6-bk/arch/ppc64/kernel/head.S~head_cleanup Wed Dec 15 10:15:43 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/head.S Wed Dec 15 15:15:17 2004 @@ -78,7 +78,7 @@ * * For iSeries: * 1. The MMU is on (as it always is for iSeries) - * 2. The kernel is entered at SystemReset_Iseries + * 2. The kernel is entered at system_reset_iSeries */ .text @@ -165,7 +165,7 @@ _GLOBAL(__secondary_hold) #else #ifdef CONFIG_SMP mr r3,r24 - b .pseries_secondary_smp_init + b .pSeries_secondary_smp_init #else BUG_OPCODE #endif @@ -305,15 +305,15 @@ exception_marker: */ #define STD_EXCEPTION_PSERIES(n, label) \ . = n; \ - .globl label##_Pseries; \ -label##_Pseries: \ + .globl label##_pSeries; \ +label##_pSeries: \ HMT_MEDIUM; \ mtspr SPRG1,r13; /* save r13 */ \ EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, label##_common) #define STD_EXCEPTION_ISERIES(n, label, area) \ - .globl label##_Iseries; \ -label##_Iseries: \ + .globl label##_iSeries; \ +label##_iSeries: \ HMT_MEDIUM; \ mtspr SPRG1,r13; /* save r13 */ \ EXCEPTION_PROLOG_ISERIES_1(area); \ @@ -321,14 +321,14 @@ label##_Iseries: \ b label##_common #define MASKABLE_EXCEPTION_ISERIES(n, label) \ - .globl label##_Iseries; \ -label##_Iseries: \ + .globl label##_iSeries; \ +label##_iSeries: \ HMT_MEDIUM; \ mtspr SPRG1,r13; /* save r13 */ \ EXCEPTION_PROLOG_ISERIES_1(PACA_EXGEN); \ lbz r10,PACAPROCENABLED(r13); \ cmpwi 0,r10,0; \ - beq- label##_Iseries_masked; \ + beq- label##_iSeries_masked; \ EXCEPTION_PROLOG_ISERIES_2; \ b label##_common; \ @@ -388,17 +388,17 @@ label##_common: \ .globl __start_interrupts __start_interrupts: - STD_EXCEPTION_PSERIES(0x100, SystemReset) + STD_EXCEPTION_PSERIES(0x100, system_reset) . = 0x200 -_MachineCheckPseries: +_machine_check_pSeries: HMT_MEDIUM mtspr SPRG1,r13 /* save r13 */ - EXCEPTION_PROLOG_PSERIES(PACA_EXMC, MachineCheck_common) + EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common) . = 0x300 - .globl DataAccess_Pseries -DataAccess_Pseries: + .globl data_access_pSeries +data_access_pSeries: HMT_MEDIUM mtspr SPRG1,r13 BEGIN_FTR_SECTION @@ -409,15 +409,15 @@ BEGIN_FTR_SECTION rlwimi r13,r12,16,0x20 mfcr r12 cmpwi r13,0x2c - beq .do_stab_bolted_Pseries + beq .do_stab_bolted_pSeries mtcrf 0x80,r12 mfspr r12,SPRG2 END_FTR_SECTION_IFCLR(CPU_FTR_SLB) - EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, DataAccess_common) + EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, data_access_common) . = 0x380 - .globl DataAccessSLB_Pseries -DataAccessSLB_Pseries: + .globl data_access_slb_pSeries +data_access_slb_pSeries: HMT_MEDIUM mtspr SPRG1,r13 mfspr r13,SPRG3 /* get paca address into r13 */ @@ -433,11 +433,11 @@ DataAccessSLB_Pseries: mfspr r3,DAR b .do_slb_miss /* Rel. branch works in real mode */ - STD_EXCEPTION_PSERIES(0x400, InstructionAccess) + STD_EXCEPTION_PSERIES(0x400, instruction_access) . = 0x480 - .globl InstructionAccessSLB_Pseries -InstructionAccessSLB_Pseries: + .globl instruction_access_slb_pSeries +instruction_access_slb_pSeries: HMT_MEDIUM mtspr SPRG1,r13 mfspr r13,SPRG3 /* get paca address into r13 */ @@ -453,25 +453,25 @@ InstructionAccessSLB_Pseries: mfspr r3,SRR0 /* SRR0 is faulting address */ b .do_slb_miss /* Rel. branch works in real mode */ - STD_EXCEPTION_PSERIES(0x500, HardwareInterrupt) - STD_EXCEPTION_PSERIES(0x600, Alignment) - STD_EXCEPTION_PSERIES(0x700, ProgramCheck) - STD_EXCEPTION_PSERIES(0x800, FPUnavailable) - STD_EXCEPTION_PSERIES(0x900, Decrementer) - STD_EXCEPTION_PSERIES(0xa00, Trap_0a) - STD_EXCEPTION_PSERIES(0xb00, Trap_0b) + STD_EXCEPTION_PSERIES(0x500, hardware_interrupt) + STD_EXCEPTION_PSERIES(0x600, alignment) + STD_EXCEPTION_PSERIES(0x700, program_check) + STD_EXCEPTION_PSERIES(0x800, fp_unavailable) + STD_EXCEPTION_PSERIES(0x900, decrementer) + STD_EXCEPTION_PSERIES(0xa00, trap_0a) + STD_EXCEPTION_PSERIES(0xb00, trap_0b) . = 0xc00 - .globl SystemCall_Pseries -SystemCall_Pseries: + .globl system_call_pSeries +system_call_pSeries: HMT_MEDIUM mr r9,r13 mfmsr r10 mfspr r13,SPRG3 mfspr r11,SRR0 clrrdi r12,r13,32 - oris r12,r12,SystemCall_common at h - ori r12,r12,SystemCall_common at l + oris r12,r12,system_call_common at h + ori r12,r12,system_call_common at l mtspr SRR0,r12 ori r10,r10,MSR_IR|MSR_DR|MSR_RI mfspr r12,SRR1 @@ -479,8 +479,8 @@ SystemCall_Pseries: rfid b . /* prevent speculative execution */ - STD_EXCEPTION_PSERIES(0xd00, SingleStep) - STD_EXCEPTION_PSERIES(0xe00, Trap_0e) + STD_EXCEPTION_PSERIES(0xd00, single_step) + STD_EXCEPTION_PSERIES(0xe00, trap_0e) /* We need to deal with the Altivec unavailable exception * here which is at 0xf20, thus in the middle of the @@ -488,18 +488,18 @@ SystemCall_Pseries: * trickery is thus necessary */ . = 0xf00 - b PerformanceMonitor_Pseries + b performance_monitor_pSeries - STD_EXCEPTION_PSERIES(0xf20, AltivecUnavailable) + STD_EXCEPTION_PSERIES(0xf20, altivec_unavailable) - STD_EXCEPTION_PSERIES(0x1300, InstructionBreakpoint) - STD_EXCEPTION_PSERIES(0x1700, AltivecAssist) + STD_EXCEPTION_PSERIES(0x1300, instruction_breakpoint) + STD_EXCEPTION_PSERIES(0x1700, altivec_assist) /* moved from 0xf00 */ - STD_EXCEPTION_PSERIES(0x3000, PerformanceMonitor) + STD_EXCEPTION_PSERIES(0x3000, performance_monitor) . = 0x3100 -_GLOBAL(do_stab_bolted_Pseries) +_GLOBAL(do_stab_bolted_pSeries) mtcrf 0x80,r12 mfspr r12,SPRG2 EXCEPTION_PROLOG_PSERIES(PACA_EXSLB, .do_stab_bolted) @@ -565,10 +565,10 @@ __end_systemcfg: /*** ISeries-LPAR interrupt handlers ***/ - STD_EXCEPTION_ISERIES(0x200, MachineCheck, PACA_EXMC) + STD_EXCEPTION_ISERIES(0x200, machine_check, PACA_EXMC) - .globl DataAccess_Iseries -DataAccess_Iseries: + .globl data_access_iSeries +data_access_iSeries: mtspr SPRG1,r13 BEGIN_FTR_SECTION mtspr SPRG2,r12 @@ -578,23 +578,23 @@ BEGIN_FTR_SECTION rlwimi r13,r12,16,0x20 mfcr r12 cmpwi r13,0x2c - beq .do_stab_bolted_Iseries + beq .do_stab_bolted_iSeries mtcrf 0x80,r12 mfspr r12,SPRG2 END_FTR_SECTION_IFCLR(CPU_FTR_SLB) EXCEPTION_PROLOG_ISERIES_1(PACA_EXGEN) EXCEPTION_PROLOG_ISERIES_2 - b DataAccess_common + b data_access_common -.do_stab_bolted_Iseries: +.do_stab_bolted_iSeries: mtcrf 0x80,r12 mfspr r12,SPRG2 EXCEPTION_PROLOG_ISERIES_1(PACA_EXSLB) EXCEPTION_PROLOG_ISERIES_2 b .do_stab_bolted - .globl DataAccessSLB_Iseries -DataAccessSLB_Iseries: + .globl data_access_slb_iSeries +data_access_slb_iSeries: mtspr SPRG1,r13 /* save r13 */ EXCEPTION_PROLOG_ISERIES_1(PACA_EXSLB) std r3,PACA_EXSLB+EX_R3(r13) @@ -602,10 +602,10 @@ DataAccessSLB_Iseries: mfspr r3,DAR b .do_slb_miss - STD_EXCEPTION_ISERIES(0x400, InstructionAccess, PACA_EXGEN) + STD_EXCEPTION_ISERIES(0x400, instruction_access, PACA_EXGEN) - .globl InstructionAccessSLB_Iseries -InstructionAccessSLB_Iseries: + .globl instruction_access_slb_iSeries +instruction_access_slb_iSeries: mtspr SPRG1,r13 /* save r13 */ EXCEPTION_PROLOG_ISERIES_1(PACA_EXSLB) std r3,PACA_EXSLB+EX_R3(r13) @@ -613,27 +613,27 @@ InstructionAccessSLB_Iseries: ld r3,PACALPPACA+LPPACASRR0(r13) b .do_slb_miss - MASKABLE_EXCEPTION_ISERIES(0x500, HardwareInterrupt) - STD_EXCEPTION_ISERIES(0x600, Alignment, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0x700, ProgramCheck, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0x800, FPUnavailable, PACA_EXGEN) - MASKABLE_EXCEPTION_ISERIES(0x900, Decrementer) - STD_EXCEPTION_ISERIES(0xa00, Trap_0a, PACA_EXGEN) - STD_EXCEPTION_ISERIES(0xb00, Trap_0b, PACA_EXGEN) + MASKABLE_EXCEPTION_ISERIES(0x500, hardware_interrupt) + STD_EXCEPTION_ISERIES(0x600, alignment, PACA_EXGEN) + STD_EXCEPTION_ISERIES(0x700, program_check, PACA_EXGEN) + STD_EXCEPTION_ISERIES(0x800, fp_unavailable, PACA_EXGEN) + MASKABLE_EXCEPTION_ISERIES(0x900, decrementer) + STD_EXCEPTION_ISERIES(0xa00, trap_0a, PACA_EXGEN) + STD_EXCEPTION_ISERIES(0xb00, trap_0b, PACA_EXGEN) - .globl SystemCall_Iseries -SystemCall_Iseries: + .globl system_call_iSeries +system_call_iSeries: mr r9,r13 mfspr r13,SPRG3 EXCEPTION_PROLOG_ISERIES_2 - b SystemCall_common + b system_call_common - STD_EXCEPTION_ISERIES( 0xd00, SingleStep, PACA_EXGEN) - STD_EXCEPTION_ISERIES( 0xe00, Trap_0e, PACA_EXGEN) - STD_EXCEPTION_ISERIES( 0xf00, PerformanceMonitor, PACA_EXGEN) + STD_EXCEPTION_ISERIES( 0xd00, single_step, PACA_EXGEN) + STD_EXCEPTION_ISERIES( 0xe00, trap_0e, PACA_EXGEN) + STD_EXCEPTION_ISERIES( 0xf00, performance_monitor, PACA_EXGEN) - .globl SystemReset_Iseries -SystemReset_Iseries: + .globl system_reset_iSeries +system_reset_iSeries: mfspr r13,SPRG3 /* Get paca address */ mfmsr r24 ori r24,r24,MSR_RI @@ -659,11 +659,11 @@ SystemReset_Iseries: subi r1,r1,STACK_FRAME_OVERHEAD cmpwi 0,r23,0 - beq iseries_secondary_smp_loop /* Loop until told to go */ + beq iSeries_secondary_smp_loop /* Loop until told to go */ #ifdef SECONDARY_PROCESSORS bne .__secondary_start /* Loop until told to go */ #endif -iseries_secondary_smp_loop: +iSeries_secondary_smp_loop: /* Let the Hypervisor know we are alive */ /* 8002 is a call to HvCallCfg::getLps, a harmless Hypervisor function */ lis r3,0x8002 @@ -683,16 +683,16 @@ iseries_secondary_smp_loop: b 1b /* If SMP not configured, secondaries * loop forever */ - .globl Decrementer_Iseries_masked -Decrementer_Iseries_masked: + .globl decrementer_iSeries_masked +decrementer_iSeries_masked: li r11,1 stb r11,PACALPPACA+LPPACADECRINT(r13) lwz r12,PACADEFAULTDECR(r13) mtspr SPRN_DEC,r12 /* fall through */ - .globl HardwareInterrupt_Iseries_masked -HardwareInterrupt_Iseries_masked: + .globl hardware_interrupt_iSeries_masked +hardware_interrupt_iSeries_masked: mtcrf 0x80,r9 /* Restore regs */ ld r11,PACALPPACA+LPPACASRR0(r13) ld r12,PACALPPACA+LPPACASRR1(r13) @@ -718,16 +718,16 @@ fwnmi_data_area: * Vectors for the FWNMI option. Share common code. */ . = 0x8000 - .globl SystemReset_FWNMI -SystemReset_FWNMI: + .globl system_reset_fwnmi +system_reset_fwnmi: HMT_MEDIUM mtspr SPRG1,r13 /* save r13 */ - EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, SystemReset_common) - .globl MachineCheck_FWNMI -MachineCheck_FWNMI: + EXCEPTION_PROLOG_PSERIES(PACA_EXGEN, system_reset_common) + .globl machine_check_fwnmi +machine_check_fwnmi: HMT_MEDIUM mtspr SPRG1,r13 /* save r13 */ - EXCEPTION_PROLOG_PSERIES(PACA_EXMC, MachineCheck_common) + EXCEPTION_PROLOG_PSERIES(PACA_EXMC, machine_check_common) /* * Space for the initial segment table @@ -745,15 +745,15 @@ __end_stab: /*** Common interrupt handlers ***/ - STD_EXCEPTION_COMMON(0x100, SystemReset, .system_reset_exception) + STD_EXCEPTION_COMMON(0x100, system_reset, .system_reset_exception) /* * Machine check is different because we use a different * save area: PACA_EXMC instead of PACA_EXGEN. */ .align 7 - .globl MachineCheck_common -MachineCheck_common: + .globl machine_check_common +machine_check_common: EXCEPTION_PROLOG_COMMON(0x200, PACA_EXMC) DISABLE_INTS bl .save_nvgprs @@ -761,17 +761,17 @@ MachineCheck_common: bl .machine_check_exception b .ret_from_except - STD_EXCEPTION_COMMON_LITE(0x900, Decrementer, .timer_interrupt) - STD_EXCEPTION_COMMON(0xa00, Trap_0a, .unknown_exception) - STD_EXCEPTION_COMMON(0xb00, Trap_0b, .unknown_exception) - STD_EXCEPTION_COMMON(0xd00, SingleStep, .single_step_exception) - STD_EXCEPTION_COMMON(0xe00, Trap_0e, .unknown_exception) - STD_EXCEPTION_COMMON(0xf00, PerformanceMonitor, .performance_monitor_exception) - STD_EXCEPTION_COMMON(0x1300, InstructionBreakpoint, .instruction_breakpoint_exception) + STD_EXCEPTION_COMMON_LITE(0x900, decrementer, .timer_interrupt) + STD_EXCEPTION_COMMON(0xa00, trap_0a, .unknown_exception) + STD_EXCEPTION_COMMON(0xb00, trap_0b, .unknown_exception) + STD_EXCEPTION_COMMON(0xd00, single_step, .single_step_exception) + STD_EXCEPTION_COMMON(0xe00, trap_0e, .unknown_exception) + STD_EXCEPTION_COMMON(0xf00, performance_monitor, .performance_monitor_exception) + STD_EXCEPTION_COMMON(0x1300, instruction_breakpoint, .instruction_breakpoint_exception) #ifdef CONFIG_ALTIVEC - STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .altivec_assist_exception) + STD_EXCEPTION_COMMON(0x1700, altivec_assist, .altivec_assist_exception) #else - STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .unknown_exception) + STD_EXCEPTION_COMMON(0x1700, altivec_assist, .unknown_exception) #endif /* @@ -861,8 +861,8 @@ unrecov_fer: * r9 - r13 are saved in paca->exgen. */ .align 7 - .globl DataAccess_common -DataAccess_common: + .globl data_access_common +data_access_common: mfspr r10,DAR std r10,PACA_EXGEN+EX_DAR(r13) mfspr r10,DSISR @@ -874,8 +874,8 @@ DataAccess_common: b .do_hash_page /* Try to handle as hpte fault */ .align 7 - .globl InstructionAccess_common -InstructionAccess_common: + .globl instruction_access_common +instruction_access_common: EXCEPTION_PROLOG_COMMON(0x400, PACA_EXGEN) ld r3,_NIP(r1) andis. r4,r12,0x5820 @@ -883,19 +883,19 @@ InstructionAccess_common: b .do_hash_page /* Try to handle as hpte fault */ .align 7 - .globl HardwareInterrupt_common - .globl HardwareInterrupt_entry -HardwareInterrupt_common: + .globl hardware_interrupt_common + .globl hardware_interrupt_entry +hardware_interrupt_common: EXCEPTION_PROLOG_COMMON(0x500, PACA_EXGEN) -HardwareInterrupt_entry: +hardware_interrupt_entry: DISABLE_INTS addi r3,r1,STACK_FRAME_OVERHEAD bl .do_IRQ b .ret_from_except_lite .align 7 - .globl Alignment_common -Alignment_common: + .globl alignment_common +alignment_common: mfspr r10,DAR std r10,PACA_EXGEN+EX_DAR(r13) mfspr r10,DSISR @@ -912,8 +912,8 @@ Alignment_common: b .ret_from_except .align 7 - .globl ProgramCheck_common -ProgramCheck_common: + .globl program_check_common +program_check_common: EXCEPTION_PROLOG_COMMON(0x700, PACA_EXGEN) bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD @@ -922,8 +922,8 @@ ProgramCheck_common: b .ret_from_except .align 7 - .globl FPUnavailable_common -FPUnavailable_common: + .globl fp_unavailable_common +fp_unavailable_common: EXCEPTION_PROLOG_COMMON(0x800, PACA_EXGEN) bne .load_up_fpu /* if from user, just load it up */ bl .save_nvgprs @@ -933,8 +933,8 @@ FPUnavailable_common: BUG_OPCODE .align 7 - .globl AltivecUnavailable_common -AltivecUnavailable_common: + .globl altivec_unavailable_common +altivec_unavailable_common: EXCEPTION_PROLOG_COMMON(0xf20, PACA_EXGEN) #ifdef CONFIG_ALTIVEC bne .load_up_altivec /* if from user, just load it up */ @@ -1195,7 +1195,7 @@ unrecov_slb: * On pSeries, secondary processors spin in the following code. * At entry, r3 = this processor's number (physical cpu id) */ -_GLOBAL(pseries_secondary_smp_init) +_GLOBAL(pSeries_secondary_smp_init) mr r24,r3 /* turn on 64-bit mode */ @@ -2108,7 +2108,7 @@ __hmt_secondary_hold: 101: #endif mr r3,r24 - b .pseries_secondary_smp_init + b .pSeries_secondary_smp_init #ifdef CONFIG_HMT _GLOBAL(hmt_start_secondary) diff -puN arch/ppc64/kernel/pSeries_smp.c~head_cleanup arch/ppc64/kernel/pSeries_smp.c --- linux-2.6-bk/arch/ppc64/kernel/pSeries_smp.c~head_cleanup Wed Dec 15 10:39:22 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/pSeries_smp.c Wed Dec 15 10:40:21 2004 @@ -57,7 +57,7 @@ #define DBG(fmt...) #endif -extern void pseries_secondary_smp_init(unsigned long); +extern void pSeries_secondary_smp_init(unsigned long); /* Get state of physical CPU. * Return codes: @@ -193,7 +193,7 @@ static inline int __devinit smp_startup_ { int status; unsigned long start_here = __pa((u32)*((unsigned long *) - pseries_secondary_smp_init)); + pSeries_secondary_smp_init)); unsigned int pcpu; /* At boot time the cpus are already spinning in hold @@ -363,7 +363,7 @@ void __init smp_init_pSeries(void) rtas_call(rtas_token("start-cpu"), 3, 1, &ret, get_hard_smp_processor_id(i), __pa((u32)*((unsigned long *) - pseries_secondary_smp_init)), + pSeries_secondary_smp_init)), i); } } diff -puN arch/ppc64/kernel/entry.S~head_cleanup arch/ppc64/kernel/entry.S --- linux-2.6-bk/arch/ppc64/kernel/entry.S~head_cleanup Wed Dec 15 10:43:34 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/entry.S Wed Dec 15 15:13:56 2004 @@ -54,8 +54,8 @@ exception_marker: #undef SHOW_SYSCALLS - .globl SystemCall_common -SystemCall_common: + .globl system_call_common +system_call_common: andi. r10,r12,MSR_PR mr r10,r1 addi r1,r1,-INT_FRAME_SIZE @@ -100,7 +100,7 @@ SystemCall_common: cmpdi cr1,r0,0x5555 /* syscall 0x5555 */ andi. r10,r12,MSR_PR /* from kernel */ crand 4*cr0+eq,4*cr1+eq,4*cr0+eq - beq HardwareInterrupt_entry + beq hardware_interrupt_entry lbz r10,PACAPROCENABLED(r13) std r10,SOFTE(r1) #endif diff -puN arch/ppc64/kernel/LparData.c~head_cleanup arch/ppc64/kernel/LparData.c --- linux-2.6-bk/arch/ppc64/kernel/LparData.c~head_cleanup Wed Dec 15 10:44:51 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/LparData.c Wed Dec 15 10:49:18 2004 @@ -61,23 +61,23 @@ struct HvReleaseData hvReleaseData = { {0} }; -extern void SystemReset_Iseries(void); -extern void MachineCheck_Iseries(void); -extern void DataAccess_Iseries(void); -extern void InstructionAccess_Iseries(void); -extern void HardwareInterrupt_Iseries(void); -extern void Alignment_Iseries(void); -extern void ProgramCheck_Iseries(void); -extern void FPUnavailable_Iseries(void); -extern void Decrementer_Iseries(void); -extern void Trap_0a_Iseries(void); -extern void Trap_0b_Iseries(void); -extern void SystemCall_Iseries(void); -extern void SingleStep_Iseries(void); -extern void Trap_0e_Iseries(void); -extern void PerformanceMonitor_Iseries(void); -extern void DataAccessSLB_Iseries(void); -extern void InstructionAccessSLB_Iseries(void); +extern void system_reset_iSeries(void); +extern void machine_check_iSeries(void); +extern void data_access_iSeries(void); +extern void instruction_access_iSeries(void); +extern void hardware_interrupt_iSeries(void); +extern void alignment_iSeries(void); +extern void program_check_iSeries(void); +extern void fp_unavailable_iSeries(void); +extern void decrementer_iSeries(void); +extern void trap_0a_iSeries(void); +extern void trap_0b_iSeries(void); +extern void system_call_iSeries(void); +extern void single_step_iSeries(void); +extern void trap_0e_iSeries(void); +extern void performance_monitor_iSeries(void); +extern void data_access_slb_iSeries(void); +extern void instruction_access_slb_iSeries(void); struct ItLpNaca itLpNaca = { 0xd397d581, /* desc = "LpNa" ebcdic */ @@ -100,27 +100,27 @@ struct ItLpNaca itLpNaca = { { 0 }, /* Old LP Queue */ { 0 }, /* 384 reserved bytes */ { - (u64)SystemReset_Iseries, /* 0x100 System Reset */ - (u64)MachineCheck_Iseries, /* 0x200 Machine Check */ - (u64)DataAccess_Iseries, /* 0x300 Data Access */ - (u64)InstructionAccess_Iseries, /* 0x400 Instruction Access */ - (u64)HardwareInterrupt_Iseries, /* 0x500 External */ - (u64)Alignment_Iseries, /* 0x600 Alignment */ - (u64)ProgramCheck_Iseries, /* 0x700 Program Check */ - (u64)FPUnavailable_Iseries, /* 0x800 FP Unavailable */ - (u64)Decrementer_Iseries, /* 0x900 Decrementer */ - (u64)Trap_0a_Iseries, /* 0xa00 Trap 0A */ - (u64)Trap_0b_Iseries, /* 0xb00 Trap 0B */ - (u64)SystemCall_Iseries, /* 0xc00 System Call */ - (u64)SingleStep_Iseries, /* 0xd00 Single Step */ - (u64)Trap_0e_Iseries, /* 0xe00 Trap 0E */ - (u64)PerformanceMonitor_Iseries,/* 0xf00 Performance Monitor */ + (u64)system_reset_iSeries, /* 0x100 System Reset */ + (u64)machine_check_iSeries, /* 0x200 Machine Check */ + (u64)data_access_iSeries, /* 0x300 Data Access */ + (u64)instruction_access_iSeries, /* 0x400 Instruction Access */ + (u64)hardware_interrupt_iSeries, /* 0x500 External */ + (u64)alignment_iSeries, /* 0x600 Alignment */ + (u64)program_check_iSeries, /* 0x700 Program Check */ + (u64)fp_unavailable_iSeries, /* 0x800 FP Unavailable */ + (u64)decrementer_iSeries, /* 0x900 Decrementer */ + (u64)trap_0a_iSeries, /* 0xa00 Trap 0A */ + (u64)trap_0b_iSeries, /* 0xb00 Trap 0B */ + (u64)system_call_iSeries, /* 0xc00 System Call */ + (u64)single_step_iSeries, /* 0xd00 Single Step */ + (u64)trap_0e_iSeries, /* 0xe00 Trap 0E */ + (u64)performance_monitor_iSeries,/* 0xf00 Performance Monitor */ 0, /* int 0x1000 */ 0, /* int 0x1010 */ 0, /* int 0x1020 CPU ctls */ - (u64)HardwareInterrupt_Iseries, /* SC Ret Hdlr */ - (u64)DataAccessSLB_Iseries, /* 0x380 D-SLB */ - (u64)InstructionAccessSLB_Iseries /* 0x480 I-SLB */ + (u64)hardware_interrupt_iSeries, /* SC Ret Hdlr */ + (u64)data_access_slb_iSeries, /* 0x380 D-SLB */ + (u64)instruction_access_slb_iSeries /* 0x480 I-SLB */ } }; EXPORT_SYMBOL(itLpNaca); diff -puN arch/ppc64/lib/sstep.c~head_cleanup arch/ppc64/lib/sstep.c --- linux-2.6-bk/arch/ppc64/lib/sstep.c~head_cleanup Wed Dec 15 10:49:45 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/lib/sstep.c Wed Dec 15 10:50:11 2004 @@ -13,7 +13,7 @@ #include #include -extern char SystemCall_common[]; +extern char system_call_common[]; /* Bits in SRR1 that are copied from MSR */ #define MSR_MASK 0xffffffff87c0ffff @@ -76,7 +76,7 @@ int emulate_step(struct pt_regs *regs, u regs->gpr[11] = regs->nip + 4; regs->gpr[12] = regs->msr & MSR_MASK; regs->gpr[13] = (unsigned long) get_paca(); - regs->nip = (unsigned long) &SystemCall_common; + regs->nip = (unsigned long) &system_call_common; regs->msr = MSR_KERNEL; return 1; case 18: /* b */ _ From moilanen at austin.ibm.com Fri Dec 17 08:40:58 2004 From: moilanen at austin.ibm.com (Jake Moilanen) Date: Thu, 16 Dec 2004 15:40:58 -0600 Subject: [PATCH 1/3] traps-cleanup In-Reply-To: <20041216153900.6b2f87e2@localhost> References: <20041216153900.6b2f87e2@localhost> Message-ID: <20041216154058.6623b165@localhost> Clean-up of traps.c. Moved the machine dependent calls to a ppc_md call, and moved the pSeries specific code to ras.c. I also changed the naming convention to more closely follow the Linux standards. Signed-off-by: Jake Moilanen --- diff -puN arch/ppc64/kernel/traps.c~traps_cleanup arch/ppc64/kernel/traps.c --- linux-2.6-bk/arch/ppc64/kernel/traps.c~traps_cleanup Tue Dec 14 17:05:09 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/traps.c Wed Dec 15 10:11:23 2004 @@ -37,11 +37,7 @@ #include #include #include - -#ifdef CONFIG_PPC_PSERIES -/* This is true if we are using the firmware NMI handler (typically LPAR) */ -extern int fwnmi_active; -#endif +#include #ifdef CONFIG_DEBUGGER int (*__debugger)(struct pt_regs *regs); @@ -133,8 +129,7 @@ int die(const char *str, struct pt_regs return 0; } -static void -_exception(int signr, struct pt_regs *regs, int code, unsigned long addr) +void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr) { siginfo_t info; @@ -150,53 +145,11 @@ _exception(int signr, struct pt_regs *re force_sig_info(signr, &info, current); } -#ifdef CONFIG_PPC_PSERIES -/* Get the error information for errors coming through the - * FWNMI vectors. The pt_regs' r3 will be updated to reflect - * the actual r3 if possible, and a ptr to the error log entry - * will be returned if found. - */ -static struct rtas_error_log *FWNMI_get_errinfo(struct pt_regs *regs) -{ - unsigned long errdata = regs->gpr[3]; - struct rtas_error_log *errhdr = NULL; - unsigned long *savep; - - if ((errdata >= 0x7000 && errdata < 0x7fff0) || - (errdata >= rtas.base && errdata < rtas.base + rtas.size - 16)) { - savep = __va(errdata); - regs->gpr[3] = savep[0]; /* restore original r3 */ - errhdr = (struct rtas_error_log *)(savep + 1); - } else { - printk("FWNMI: corrupt r3\n"); - } - return errhdr; -} - -/* Call this when done with the data returned by FWNMI_get_errinfo. - * It will release the saved data area for other CPUs in the - * partition to receive FWNMI errors. - */ -static void FWNMI_release_errinfo(void) -{ - int ret = rtas_call(rtas_token("ibm,nmi-interlock"), 0, 1, NULL); - if (ret != 0) - printk("FWNMI: nmi-interlock failed: %d\n", ret); -} -#endif - -void -SystemResetException(struct pt_regs *regs) +void system_reset_exception(struct pt_regs *regs) { -#ifdef CONFIG_PPC_PSERIES - if (fwnmi_active) { - struct rtas_error_log *errhdr = FWNMI_get_errinfo(regs); - if (errhdr) { - /* XXX Should look at FWNMI information */ - } - FWNMI_release_errinfo(); - } -#endif + /* See if any machine dependent calls */ + if (ppc_md.system_reset_exception) + ppc_md.system_reset_exception(regs); die("System Reset", regs, 0); @@ -207,64 +160,16 @@ SystemResetException(struct pt_regs *reg /* What should we do here? We could issue a shutdown or hard reset. */ } -#ifdef CONFIG_PPC_PSERIES -/* - * See if we can recover from a machine check exception. - * This is only called on power4 (or above) and only via - * the Firmware Non-Maskable Interrupts (fwnmi) handler - * which provides the error analysis for us. - * - * Return 1 if corrected (or delivered a signal). - * Return 0 if there is nothing we can do. - */ -static int recover_mce(struct pt_regs *regs, struct rtas_error_log err) +void machine_check_exception(struct pt_regs *regs) { - if (err.disposition == RTAS_DISP_FULLY_RECOVERED) { - /* Platform corrected itself */ - return 1; - } else if ((regs->msr & MSR_RI) && - user_mode(regs) && - err.severity == RTAS_SEVERITY_ERROR_SYNC && - err.disposition == RTAS_DISP_NOT_RECOVERED && - err.target == RTAS_TARGET_MEMORY && - err.type == RTAS_TYPE_ECC_UNCORR && - !(current->pid == 0 || current->pid == 1)) { - /* Kill off a user process with an ECC error */ - printk(KERN_ERR "MCE: uncorrectable ecc error for pid %d\n", - current->pid); - /* XXX something better for ECC error? */ - _exception(SIGBUS, regs, BUS_ADRERR, regs->nip); - return 1; - } - return 0; -} -#endif + int recover = 0; + + /* See if any machine dependent calls */ + if (ppc_md.machine_check_exception) + recover = ppc_md.machine_check_exception(regs); -/* - * Handle a machine check. - * - * Note that on Power 4 and beyond Firmware Non-Maskable Interrupts (fwnmi) - * should be present. If so the handler which called us tells us if the - * error was recovered (never true if RI=0). - * - * On hardware prior to Power 4 these exceptions were asynchronous which - * means we can't tell exactly where it occurred and so we can't recover. - */ -void -MachineCheckException(struct pt_regs *regs) -{ -#ifdef CONFIG_PPC_PSERIES - struct rtas_error_log err, *errp; - - if (fwnmi_active) { - errp = FWNMI_get_errinfo(regs); - if (errp) - err = *errp; - FWNMI_release_errinfo(); /* frees errp */ - if (errp && recover_mce(regs, err)) - return; - } -#endif + if (recover) + return; if (debugger_fault_handler(regs)) return; @@ -275,8 +180,7 @@ MachineCheckException(struct pt_regs *re panic("Unrecoverable Machine check"); } -void -UnknownException(struct pt_regs *regs) +void unknown_exception(struct pt_regs *regs) { printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n", regs->nip, regs->msr, regs->trap); @@ -284,16 +188,14 @@ UnknownException(struct pt_regs *regs) _exception(SIGTRAP, regs, 0, 0); } -void -InstructionBreakpointException(struct pt_regs *regs) +void instruction_breakpoint_exception(struct pt_regs *regs) { if (debugger_iabr_match(regs)) return; _exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip); } -void -SingleStepException(struct pt_regs *regs) +void single_step_exception(struct pt_regs *regs) { regs->msr &= ~MSR_SE; /* Turn off 'trace' bit */ @@ -312,7 +214,7 @@ SingleStepException(struct pt_regs *regs static inline void emulate_single_step(struct pt_regs *regs) { if (regs->msr & MSR_SE) - SingleStepException(regs); + single_step_exception(regs); } static void parse_fpe(struct pt_regs *regs) @@ -456,8 +358,7 @@ check_bug_trap(struct pt_regs *regs) return 0; } -void -ProgramCheckException(struct pt_regs *regs) +void program_check_exception(struct pt_regs *regs) { if (regs->msr & 0x100000) { /* IEEE FP exception */ @@ -498,14 +399,14 @@ ProgramCheckException(struct pt_regs *re } } -void KernelFPUnavailableException(struct pt_regs *regs) +void kernel_fp_unavailable_exception(struct pt_regs *regs) { printk(KERN_EMERG "Unrecoverable FP Unavailable Exception " "%lx at %lx\n", regs->trap, regs->nip); die("Unrecoverable FP Unavailable Exception", regs, SIGABRT); } -void AltivecUnavailableException(struct pt_regs *regs) +void altivec_unavailable_exception(struct pt_regs *regs) { #ifndef CONFIG_ALTIVEC if (user_mode(regs)) { @@ -536,14 +437,12 @@ void (*perf_irq)(struct pt_regs *) = dum EXPORT_SYMBOL(perf_irq); -void -PerformanceMonitorException(struct pt_regs *regs) +void performance_monitor_exception(struct pt_regs *regs) { perf_irq(regs); } -void -AlignmentException(struct pt_regs *regs) +void alignment_exception(struct pt_regs *regs) { int fixed; @@ -571,8 +470,7 @@ AlignmentException(struct pt_regs *regs) } #ifdef CONFIG_ALTIVEC -void -AltivecAssistException(struct pt_regs *regs) +void altivec_assist_exception(struct pt_regs *regs) { int err; siginfo_t info; diff -puN arch/ppc64/kernel/ras.c~traps_cleanup arch/ppc64/kernel/ras.c --- linux-2.6-bk/arch/ppc64/kernel/ras.c~traps_cleanup Tue Dec 14 17:05:17 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/ras.c Wed Dec 15 10:06:46 2004 @@ -55,6 +55,9 @@ static unsigned char ras_log_buf[RTAS_ERROR_LOG_MAX]; static spinlock_t ras_log_buf_lock = SPIN_LOCK_UNLOCKED; +/* This is true if we are using the firmware NMI handler (typically LPAR) */ +extern int fwnmi_active; + static int ras_get_sensor_state_token; static int ras_check_exception_token; @@ -233,4 +236,105 @@ ras_error_interrupt(int irq, void *dev_i spin_unlock(&ras_log_buf_lock); return IRQ_HANDLED; +} + +/* Get the error information for errors coming through the + * FWNMI vectors. The pt_regs' r3 will be updated to reflect + * the actual r3 if possible, and a ptr to the error log entry + * will be returned if found. + */ +static struct rtas_error_log *FWNMI_get_errinfo(struct pt_regs *regs) +{ + unsigned long errdata = regs->gpr[3]; + struct rtas_error_log *errhdr = NULL; + unsigned long *savep; + + if ((errdata >= 0x7000 && errdata < 0x7fff0) || + (errdata >= rtas.base && errdata < rtas.base + rtas.size - 16)) { + savep = __va(errdata); + regs->gpr[3] = savep[0]; /* restore original r3 */ + errhdr = (struct rtas_error_log *)(savep + 1); + } else { + printk("FWNMI: corrupt r3\n"); + } + return errhdr; +} + +/* Call this when done with the data returned by FWNMI_get_errinfo. + * It will release the saved data area for other CPUs in the + * partition to receive FWNMI errors. + */ +static void FWNMI_release_errinfo(void) +{ + int ret = rtas_call(rtas_token("ibm,nmi-interlock"), 0, 1, NULL); + if (ret != 0) + printk("FWNMI: nmi-interlock failed: %d\n", ret); +} + +void pSeries_system_reset_exception(struct pt_regs *regs) +{ + if (fwnmi_active) { + struct rtas_error_log *errhdr = FWNMI_get_errinfo(regs); + if (errhdr) { + /* XXX Should look at FWNMI information */ + } + FWNMI_release_errinfo(); + } +} + +/* + * See if we can recover from a machine check exception. + * This is only called on power4 (or above) and only via + * the Firmware Non-Maskable Interrupts (fwnmi) handler + * which provides the error analysis for us. + * + * Return 1 if corrected (or delivered a signal). + * Return 0 if there is nothing we can do. + */ +static int recover_mce(struct pt_regs *regs, struct rtas_error_log err) +{ + if (err.disposition == RTAS_DISP_FULLY_RECOVERED) { + /* Platform corrected itself */ + return 1; + } else if ((regs->msr & MSR_RI) && + user_mode(regs) && + err.severity == RTAS_SEVERITY_ERROR_SYNC && + err.disposition == RTAS_DISP_NOT_RECOVERED && + err.target == RTAS_TARGET_MEMORY && + err.type == RTAS_TYPE_ECC_UNCORR && + !(current->pid == 0 || current->pid == 1)) { + /* Kill off a user process with an ECC error */ + printk(KERN_ERR "MCE: uncorrectable ecc error for pid %d\n", + current->pid); + /* XXX something better for ECC error? */ + _exception(SIGBUS, regs, BUS_ADRERR, regs->nip); + return 1; + } + return 0; +} + +/* + * Handle a machine check. + * + * Note that on Power 4 and beyond Firmware Non-Maskable Interrupts (fwnmi) + * should be present. If so the handler which called us tells us if the + * error was recovered (never true if RI=0). + * + * On hardware prior to Power 4 these exceptions were asynchronous which + * means we can't tell exactly where it occurred and so we can't recover. + */ +int pSeries_machine_check_exception(struct pt_regs *regs) +{ + struct rtas_error_log err, *errp; + + if (fwnmi_active) { + errp = FWNMI_get_errinfo(regs); + if (errp) + err = *errp; + FWNMI_release_errinfo(); /* frees errp */ + if (errp && recover_mce(regs, err)) + return 1; + } + + return 0; } diff -puN arch/ppc64/kernel/head.S~traps_cleanup arch/ppc64/kernel/head.S --- linux-2.6-bk/arch/ppc64/kernel/head.S~traps_cleanup Tue Dec 14 17:12:18 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/head.S Tue Dec 14 17:29:44 2004 @@ -745,7 +745,7 @@ __end_stab: /*** Common interrupt handlers ***/ - STD_EXCEPTION_COMMON(0x100, SystemReset, .SystemResetException) + STD_EXCEPTION_COMMON(0x100, SystemReset, .system_reset_exception) /* * Machine check is different because we use a different @@ -758,20 +758,20 @@ MachineCheck_common: DISABLE_INTS bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD - bl .MachineCheckException + bl .machine_check_exception b .ret_from_except STD_EXCEPTION_COMMON_LITE(0x900, Decrementer, .timer_interrupt) - STD_EXCEPTION_COMMON(0xa00, Trap_0a, .UnknownException) - STD_EXCEPTION_COMMON(0xb00, Trap_0b, .UnknownException) - STD_EXCEPTION_COMMON(0xd00, SingleStep, .SingleStepException) - STD_EXCEPTION_COMMON(0xe00, Trap_0e, .UnknownException) - STD_EXCEPTION_COMMON(0xf00, PerformanceMonitor, .PerformanceMonitorException) - STD_EXCEPTION_COMMON(0x1300, InstructionBreakpoint, .InstructionBreakpointException) + STD_EXCEPTION_COMMON(0xa00, Trap_0a, .unknown_exception) + STD_EXCEPTION_COMMON(0xb00, Trap_0b, .unknown_exception) + STD_EXCEPTION_COMMON(0xd00, SingleStep, .single_step_exception) + STD_EXCEPTION_COMMON(0xe00, Trap_0e, .unknown_exception) + STD_EXCEPTION_COMMON(0xf00, PerformanceMonitor, .performance_monitor_exception) + STD_EXCEPTION_COMMON(0x1300, InstructionBreakpoint, .instruction_breakpoint_exception) #ifdef CONFIG_ALTIVEC - STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .AltivecAssistException) + STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .altivec_assist_exception) #else - STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .UnknownException) + STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .unknown_exception) #endif /* @@ -908,7 +908,7 @@ Alignment_common: bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD ENABLE_INTS - bl .AlignmentException + bl .alignment_exception b .ret_from_except .align 7 @@ -918,7 +918,7 @@ ProgramCheck_common: bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD ENABLE_INTS - bl .ProgramCheckException + bl .program_check_exception b .ret_from_except .align 7 @@ -929,7 +929,7 @@ FPUnavailable_common: bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD ENABLE_INTS - bl .KernelFPUnavailableException + bl .kernel_fp_unavailable_exception BUG_OPCODE .align 7 @@ -942,7 +942,7 @@ AltivecUnavailable_common: bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD ENABLE_INTS - bl .AltivecUnavailableException + bl .altivec_unavailable_exception b .ret_from_except /* diff -puN include/asm-ppc64/machdep.h~traps_cleanup include/asm-ppc64/machdep.h --- linux-2.6-bk/include/asm-ppc64/machdep.h~traps_cleanup Wed Dec 15 09:31:23 2004 +++ linux-2.6-bk-moilanen/include/asm-ppc64/machdep.h Wed Dec 15 10:07:00 2004 @@ -110,6 +110,10 @@ struct machdep_calls { ssize_t (*nvram_size)(void); int (*nvram_sync)(void); + /* Exception handlers */ + void (*system_reset_exception)(struct pt_regs *regs); + int (*machine_check_exception)(struct pt_regs *regs); + /* Motherboard/chipset features. This is a kind of general purpose * hook used to control some machine specific features (like reset * lines, chip power control, etc...). diff -puN arch/ppc64/kernel/pSeries_setup.c~traps_cleanup arch/ppc64/kernel/pSeries_setup.c --- linux-2.6-bk/arch/ppc64/kernel/pSeries_setup.c~traps_cleanup Wed Dec 15 10:02:40 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/pSeries_setup.c Wed Dec 15 10:13:32 2004 @@ -92,6 +92,9 @@ extern unsigned long loops_per_jiffy; extern unsigned long ppc_proc_freq; extern unsigned long ppc_tb_freq; +extern void pSeries_system_reset_exception(struct pt_regs *regs); +extern int pSeries_machine_check_exception(struct pt_regs *regs); + static volatile void __iomem * chrp_int_ack_special; struct mpic *pSeries_mpic; @@ -610,4 +613,6 @@ struct machdep_calls __initdata pSeries_ .calibrate_decr = pSeries_calibrate_decr, .progress = pSeries_progress, .check_legacy_ioport = pSeries_check_legacy_ioport, + .system_reset_exception = pSeries_system_reset_exception, + .machine_check_exception = pSeries_machine_check_exception, }; _ From moilanen at austin.ibm.com Fri Dec 17 09:05:35 2004 From: moilanen at austin.ibm.com (Jake Moilanen) Date: Thu, 16 Dec 2004 16:05:35 -0600 Subject: [PATCH 1/3] traps-cleanup In-Reply-To: <20041216154058.6623b165@localhost> References: <20041216153900.6b2f87e2@localhost> <20041216154058.6623b165@localhost> Message-ID: <20041216160535.0b325e4f@localhost> Ahh..please disregard this first 1/3, I forgot to refpatch the first one before I sent it. Here's the correct version. Signed-off-by: Jake Moilanen --- diff -puN arch/ppc64/kernel/traps.c~traps_cleanup arch/ppc64/kernel/traps.c --- linux-2.6-bk/arch/ppc64/kernel/traps.c~traps_cleanup Tue Dec 14 17:05:09 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/traps.c Wed Dec 15 10:11:23 2004 @@ -37,11 +37,7 @@ #include #include #include - -#ifdef CONFIG_PPC_PSERIES -/* This is true if we are using the firmware NMI handler (typically LPAR) */ -extern int fwnmi_active; -#endif +#include #ifdef CONFIG_DEBUGGER int (*__debugger)(struct pt_regs *regs); @@ -133,8 +129,7 @@ int die(const char *str, struct pt_regs return 0; } -static void -_exception(int signr, struct pt_regs *regs, int code, unsigned long addr) +void _exception(int signr, struct pt_regs *regs, int code, unsigned long addr) { siginfo_t info; @@ -150,53 +145,11 @@ _exception(int signr, struct pt_regs *re force_sig_info(signr, &info, current); } -#ifdef CONFIG_PPC_PSERIES -/* Get the error information for errors coming through the - * FWNMI vectors. The pt_regs' r3 will be updated to reflect - * the actual r3 if possible, and a ptr to the error log entry - * will be returned if found. - */ -static struct rtas_error_log *FWNMI_get_errinfo(struct pt_regs *regs) -{ - unsigned long errdata = regs->gpr[3]; - struct rtas_error_log *errhdr = NULL; - unsigned long *savep; - - if ((errdata >= 0x7000 && errdata < 0x7fff0) || - (errdata >= rtas.base && errdata < rtas.base + rtas.size - 16)) { - savep = __va(errdata); - regs->gpr[3] = savep[0]; /* restore original r3 */ - errhdr = (struct rtas_error_log *)(savep + 1); - } else { - printk("FWNMI: corrupt r3\n"); - } - return errhdr; -} - -/* Call this when done with the data returned by FWNMI_get_errinfo. - * It will release the saved data area for other CPUs in the - * partition to receive FWNMI errors. - */ -static void FWNMI_release_errinfo(void) -{ - int ret = rtas_call(rtas_token("ibm,nmi-interlock"), 0, 1, NULL); - if (ret != 0) - printk("FWNMI: nmi-interlock failed: %d\n", ret); -} -#endif - -void -SystemResetException(struct pt_regs *regs) +void system_reset_exception(struct pt_regs *regs) { -#ifdef CONFIG_PPC_PSERIES - if (fwnmi_active) { - struct rtas_error_log *errhdr = FWNMI_get_errinfo(regs); - if (errhdr) { - /* XXX Should look at FWNMI information */ - } - FWNMI_release_errinfo(); - } -#endif + /* See if any machine dependent calls */ + if (ppc_md.system_reset_exception) + ppc_md.system_reset_exception(regs); die("System Reset", regs, 0); @@ -207,64 +160,16 @@ SystemResetException(struct pt_regs *reg /* What should we do here? We could issue a shutdown or hard reset. */ } -#ifdef CONFIG_PPC_PSERIES -/* - * See if we can recover from a machine check exception. - * This is only called on power4 (or above) and only via - * the Firmware Non-Maskable Interrupts (fwnmi) handler - * which provides the error analysis for us. - * - * Return 1 if corrected (or delivered a signal). - * Return 0 if there is nothing we can do. - */ -static int recover_mce(struct pt_regs *regs, struct rtas_error_log err) +void machine_check_exception(struct pt_regs *regs) { - if (err.disposition == RTAS_DISP_FULLY_RECOVERED) { - /* Platform corrected itself */ - return 1; - } else if ((regs->msr & MSR_RI) && - user_mode(regs) && - err.severity == RTAS_SEVERITY_ERROR_SYNC && - err.disposition == RTAS_DISP_NOT_RECOVERED && - err.target == RTAS_TARGET_MEMORY && - err.type == RTAS_TYPE_ECC_UNCORR && - !(current->pid == 0 || current->pid == 1)) { - /* Kill off a user process with an ECC error */ - printk(KERN_ERR "MCE: uncorrectable ecc error for pid %d\n", - current->pid); - /* XXX something better for ECC error? */ - _exception(SIGBUS, regs, BUS_ADRERR, regs->nip); - return 1; - } - return 0; -} -#endif + int recover = 0; + + /* See if any machine dependent calls */ + if (ppc_md.machine_check_exception) + recover = ppc_md.machine_check_exception(regs); -/* - * Handle a machine check. - * - * Note that on Power 4 and beyond Firmware Non-Maskable Interrupts (fwnmi) - * should be present. If so the handler which called us tells us if the - * error was recovered (never true if RI=0). - * - * On hardware prior to Power 4 these exceptions were asynchronous which - * means we can't tell exactly where it occurred and so we can't recover. - */ -void -MachineCheckException(struct pt_regs *regs) -{ -#ifdef CONFIG_PPC_PSERIES - struct rtas_error_log err, *errp; - - if (fwnmi_active) { - errp = FWNMI_get_errinfo(regs); - if (errp) - err = *errp; - FWNMI_release_errinfo(); /* frees errp */ - if (errp && recover_mce(regs, err)) - return; - } -#endif + if (recover) + return; if (debugger_fault_handler(regs)) return; @@ -275,8 +180,7 @@ MachineCheckException(struct pt_regs *re panic("Unrecoverable Machine check"); } -void -UnknownException(struct pt_regs *regs) +void unknown_exception(struct pt_regs *regs) { printk("Bad trap at PC: %lx, SR: %lx, vector=%lx\n", regs->nip, regs->msr, regs->trap); @@ -284,16 +188,14 @@ UnknownException(struct pt_regs *regs) _exception(SIGTRAP, regs, 0, 0); } -void -InstructionBreakpointException(struct pt_regs *regs) +void instruction_breakpoint_exception(struct pt_regs *regs) { if (debugger_iabr_match(regs)) return; _exception(SIGTRAP, regs, TRAP_BRKPT, regs->nip); } -void -SingleStepException(struct pt_regs *regs) +void single_step_exception(struct pt_regs *regs) { regs->msr &= ~MSR_SE; /* Turn off 'trace' bit */ @@ -312,7 +214,7 @@ SingleStepException(struct pt_regs *regs static inline void emulate_single_step(struct pt_regs *regs) { if (regs->msr & MSR_SE) - SingleStepException(regs); + single_step_exception(regs); } static void parse_fpe(struct pt_regs *regs) @@ -456,8 +358,7 @@ check_bug_trap(struct pt_regs *regs) return 0; } -void -ProgramCheckException(struct pt_regs *regs) +void program_check_exception(struct pt_regs *regs) { if (regs->msr & 0x100000) { /* IEEE FP exception */ @@ -498,14 +399,14 @@ ProgramCheckException(struct pt_regs *re } } -void KernelFPUnavailableException(struct pt_regs *regs) +void kernel_fp_unavailable_exception(struct pt_regs *regs) { printk(KERN_EMERG "Unrecoverable FP Unavailable Exception " "%lx at %lx\n", regs->trap, regs->nip); die("Unrecoverable FP Unavailable Exception", regs, SIGABRT); } -void AltivecUnavailableException(struct pt_regs *regs) +void altivec_unavailable_exception(struct pt_regs *regs) { #ifndef CONFIG_ALTIVEC if (user_mode(regs)) { @@ -536,14 +437,12 @@ void (*perf_irq)(struct pt_regs *) = dum EXPORT_SYMBOL(perf_irq); -void -PerformanceMonitorException(struct pt_regs *regs) +void performance_monitor_exception(struct pt_regs *regs) { perf_irq(regs); } -void -AlignmentException(struct pt_regs *regs) +void alignment_exception(struct pt_regs *regs) { int fixed; @@ -571,8 +470,7 @@ AlignmentException(struct pt_regs *regs) } #ifdef CONFIG_ALTIVEC -void -AltivecAssistException(struct pt_regs *regs) +void altivec_assist_exception(struct pt_regs *regs) { int err; siginfo_t info; diff -puN arch/ppc64/kernel/ras.c~traps_cleanup arch/ppc64/kernel/ras.c --- linux-2.6-bk/arch/ppc64/kernel/ras.c~traps_cleanup Tue Dec 14 17:05:17 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/ras.c Thu Dec 16 16:03:03 2004 @@ -55,6 +55,9 @@ static unsigned char ras_log_buf[RTAS_ERROR_LOG_MAX]; static spinlock_t ras_log_buf_lock = SPIN_LOCK_UNLOCKED; +/* This is true if we are using the firmware NMI handler (typically LPAR) */ +extern int fwnmi_active; + static int ras_get_sensor_state_token; static int ras_check_exception_token; @@ -233,4 +236,105 @@ ras_error_interrupt(int irq, void *dev_i spin_unlock(&ras_log_buf_lock); return IRQ_HANDLED; +} + +/* Get the error information for errors coming through the + * FWNMI vectors. The pt_regs' r3 will be updated to reflect + * the actual r3 if possible, and a ptr to the error log entry + * will be returned if found. + */ +static struct rtas_error_log *fwnmi_get_errinfo(struct pt_regs *regs) +{ + unsigned long errdata = regs->gpr[3]; + struct rtas_error_log *errhdr = NULL; + unsigned long *savep; + + if ((errdata >= 0x7000 && errdata < 0x7fff0) || + (errdata >= rtas.base && errdata < rtas.base + rtas.size - 16)) { + savep = __va(errdata); + regs->gpr[3] = savep[0]; /* restore original r3 */ + errhdr = (struct rtas_error_log *)(savep + 1); + } else { + printk("FWNMI: corrupt r3\n"); + } + return errhdr; +} + +/* Call this when done with the data returned by FWNMI_get_errinfo. + * It will release the saved data area for other CPUs in the + * partition to receive FWNMI errors. + */ +static void fwnmi_release_errinfo(void) +{ + int ret = rtas_call(rtas_token("ibm,nmi-interlock"), 0, 1, NULL); + if (ret != 0) + printk("FWNMI: nmi-interlock failed: %d\n", ret); +} + +void pSeries_system_reset_exception(struct pt_regs *regs) +{ + if (fwnmi_active) { + struct rtas_error_log *errhdr = fwnmi_get_errinfo(regs); + if (errhdr) { + /* XXX Should look at FWNMI information */ + } + fwnmi_release_errinfo(); + } +} + +/* + * See if we can recover from a machine check exception. + * This is only called on power4 (or above) and only via + * the Firmware Non-Maskable Interrupts (fwnmi) handler + * which provides the error analysis for us. + * + * Return 1 if corrected (or delivered a signal). + * Return 0 if there is nothing we can do. + */ +static int recover_mce(struct pt_regs *regs, struct rtas_error_log err) +{ + if (err.disposition == RTAS_DISP_FULLY_RECOVERED) { + /* Platform corrected itself */ + return 1; + } else if ((regs->msr & MSR_RI) && + user_mode(regs) && + err.severity == RTAS_SEVERITY_ERROR_SYNC && + err.disposition == RTAS_DISP_NOT_RECOVERED && + err.target == RTAS_TARGET_MEMORY && + err.type == RTAS_TYPE_ECC_UNCORR && + !(current->pid == 0 || current->pid == 1)) { + /* Kill off a user process with an ECC error */ + printk(KERN_ERR "MCE: uncorrectable ecc error for pid %d\n", + current->pid); + /* XXX something better for ECC error? */ + _exception(SIGBUS, regs, BUS_ADRERR, regs->nip); + return 1; + } + return 0; +} + +/* + * Handle a machine check. + * + * Note that on Power 4 and beyond Firmware Non-Maskable Interrupts (fwnmi) + * should be present. If so the handler which called us tells us if the + * error was recovered (never true if RI=0). + * + * On hardware prior to Power 4 these exceptions were asynchronous which + * means we can't tell exactly where it occurred and so we can't recover. + */ +int pSeries_machine_check_exception(struct pt_regs *regs) +{ + struct rtas_error_log err, *errp; + + if (fwnmi_active) { + errp = fwnmi_get_errinfo(regs); + if (errp) + err = *errp; + fwnmi_release_errinfo(); /* frees errp */ + if (errp && recover_mce(regs, err)) + return 1; + } + + return 0; } diff -puN arch/ppc64/kernel/head.S~traps_cleanup arch/ppc64/kernel/head.S --- linux-2.6-bk/arch/ppc64/kernel/head.S~traps_cleanup Tue Dec 14 17:12:18 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/head.S Thu Dec 16 16:03:10 2004 @@ -745,7 +745,7 @@ __end_stab: /*** Common interrupt handlers ***/ - STD_EXCEPTION_COMMON(0x100, SystemReset, .SystemResetException) + STD_EXCEPTION_COMMON(0x100, SystemReset, .system_reset_exception) /* * Machine check is different because we use a different @@ -758,20 +758,20 @@ MachineCheck_common: DISABLE_INTS bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD - bl .MachineCheckException + bl .machine_check_exception b .ret_from_except STD_EXCEPTION_COMMON_LITE(0x900, Decrementer, .timer_interrupt) - STD_EXCEPTION_COMMON(0xa00, Trap_0a, .UnknownException) - STD_EXCEPTION_COMMON(0xb00, Trap_0b, .UnknownException) - STD_EXCEPTION_COMMON(0xd00, SingleStep, .SingleStepException) - STD_EXCEPTION_COMMON(0xe00, Trap_0e, .UnknownException) - STD_EXCEPTION_COMMON(0xf00, PerformanceMonitor, .PerformanceMonitorException) - STD_EXCEPTION_COMMON(0x1300, InstructionBreakpoint, .InstructionBreakpointException) + STD_EXCEPTION_COMMON(0xa00, Trap_0a, .unknown_exception) + STD_EXCEPTION_COMMON(0xb00, Trap_0b, .unknown_exception) + STD_EXCEPTION_COMMON(0xd00, SingleStep, .single_step_exception) + STD_EXCEPTION_COMMON(0xe00, Trap_0e, .unknown_exception) + STD_EXCEPTION_COMMON(0xf00, PerformanceMonitor, .performance_monitor_exception) + STD_EXCEPTION_COMMON(0x1300, InstructionBreakpoint, .instruction_breakpoint_exception) #ifdef CONFIG_ALTIVEC - STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .AltivecAssistException) + STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .altivec_assist_exception) #else - STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .UnknownException) + STD_EXCEPTION_COMMON(0x1700, AltivecAssist, .unknown_exception) #endif /* @@ -908,7 +908,7 @@ Alignment_common: bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD ENABLE_INTS - bl .AlignmentException + bl .alignment_exception b .ret_from_except .align 7 @@ -918,7 +918,7 @@ ProgramCheck_common: bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD ENABLE_INTS - bl .ProgramCheckException + bl .program_check_exception b .ret_from_except .align 7 @@ -929,7 +929,7 @@ FPUnavailable_common: bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD ENABLE_INTS - bl .KernelFPUnavailableException + bl .kernel_fp_unavailable_exception BUG_OPCODE .align 7 @@ -942,7 +942,7 @@ AltivecUnavailable_common: bl .save_nvgprs addi r3,r1,STACK_FRAME_OVERHEAD ENABLE_INTS - bl .AltivecUnavailableException + bl .altivec_unavailable_exception b .ret_from_except /* diff -puN include/asm-ppc64/machdep.h~traps_cleanup include/asm-ppc64/machdep.h --- linux-2.6-bk/include/asm-ppc64/machdep.h~traps_cleanup Wed Dec 15 09:31:23 2004 +++ linux-2.6-bk-moilanen/include/asm-ppc64/machdep.h Wed Dec 15 10:07:00 2004 @@ -110,6 +110,10 @@ struct machdep_calls { ssize_t (*nvram_size)(void); int (*nvram_sync)(void); + /* Exception handlers */ + void (*system_reset_exception)(struct pt_regs *regs); + int (*machine_check_exception)(struct pt_regs *regs); + /* Motherboard/chipset features. This is a kind of general purpose * hook used to control some machine specific features (like reset * lines, chip power control, etc...). diff -puN arch/ppc64/kernel/pSeries_setup.c~traps_cleanup arch/ppc64/kernel/pSeries_setup.c --- linux-2.6-bk/arch/ppc64/kernel/pSeries_setup.c~traps_cleanup Wed Dec 15 10:02:40 2004 +++ linux-2.6-bk-moilanen/arch/ppc64/kernel/pSeries_setup.c Wed Dec 15 10:38:20 2004 @@ -80,7 +80,7 @@ extern void pSeries_get_boot_time(struct extern void pSeries_get_rtc_time(struct rtc_time *rtc_time); extern int pSeries_set_rtc_time(struct rtc_time *rtc_time); extern void find_udbg_vterm(void); -extern void SystemReset_FWNMI(void), MachineCheck_FWNMI(void); /* from head.S */ +extern void system_reset_fwnmi(void), machine_check_fwnmi(void); /* from head.S */ extern void generic_find_legacy_serial_ports(unsigned int *default_speed); int fwnmi_active; /* TRUE if an FWNMI handler is present */ @@ -92,6 +92,9 @@ extern unsigned long loops_per_jiffy; extern unsigned long ppc_proc_freq; extern unsigned long ppc_tb_freq; +extern void pSeries_system_reset_exception(struct pt_regs *regs); +extern int pSeries_machine_check_exception(struct pt_regs *regs); + static volatile void __iomem * chrp_int_ack_special; struct mpic *pSeries_mpic; @@ -118,8 +121,8 @@ static void __init fwnmi_init(void) if (ibm_nmi_register == RTAS_UNKNOWN_SERVICE) return; ret = rtas_call(ibm_nmi_register, 2, 1, NULL, - __pa((unsigned long)SystemReset_FWNMI), - __pa((unsigned long)MachineCheck_FWNMI)); + __pa((unsigned long)system_reset_fwnmi), + __pa((unsigned long)machine_check_fwnmi)); if (ret == 0) fwnmi_active = 1; } @@ -610,4 +613,6 @@ struct machdep_calls __initdata pSeries_ .calibrate_decr = pSeries_calibrate_decr, .progress = pSeries_progress, .check_legacy_ioport = pSeries_check_legacy_ioport, + .system_reset_exception = pSeries_system_reset_exception, + .machine_check_exception = pSeries_machine_check_exception, }; _ From nacc at us.ibm.com Sat Dec 18 11:54:45 2004 From: nacc at us.ibm.com (Nishanth Aravamudan) Date: Fri, 17 Dec 2004 16:54:45 -0800 Subject: {rtasd,rtc,scanlog}.c schedule_timeout() usage Message-ID: <20041218005445.GE2397@us.ibm.com> Hi, I'm trying to work some more on auditing the usage of schedule_timeout(), replacing most calls with either msleep() or msleep_interruptible(), depending on the state to sleep in. I am now begginning to replace code outside of drivers and came across arch/ppc64/kernel/{rtc,rtasd,scanlog}.c, all of which use TASK_INTERRUPTIBLE schedule_timeout() calls. My understand, though, is that TASK_INTERRUPTIBLE directly indicates that one should be able to handle waking up early if a signal is received. I don't see any signal handling / responding in the code around these timeouts. Would TASK_UNINTERRUPTIBLE work in these cases (indicating sleeping for waitqueue events (which I don't see around the code, so I'm guessing means an absolute sleep). If the latter, then perhaps I can use msleep_interruptible(). If you only wish to sleep until a signal is received (or the timeout occurs) then msleep_interruptible() may be a valid choice. Please let me know what you think. Thanks, Nish From benh at kernel.crashing.org Sat Dec 18 19:41:35 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sat, 18 Dec 2004 09:41:35 +0100 Subject: {rtasd,rtc,scanlog}.c schedule_timeout() usage In-Reply-To: <20041218005445.GE2397@us.ibm.com> References: <20041218005445.GE2397@us.ibm.com> Message-ID: <1103359295.17734.6.camel@gaston> On Fri, 2004-12-17 at 16:54 -0800, Nishanth Aravamudan wrote: > Hi, > > I'm trying to work some more on auditing the usage of schedule_timeout(), > replacing most calls with either msleep() or msleep_interruptible(), depending > on the state to sleep in. I am now begginning to replace code outside of drivers > and came across arch/ppc64/kernel/{rtc,rtasd,scanlog}.c, all of which use > TASK_INTERRUPTIBLE schedule_timeout() calls. > > My understand, though, is that TASK_INTERRUPTIBLE directly indicates that one > should be able to handle waking up early if a signal is received. I don't see > any signal handling / responding in the code around these timeouts. Would > TASK_UNINTERRUPTIBLE work in these cases (indicating sleeping for waitqueue > events (which I don't see around the code, so I'm guessing means an absolute > sleep). If the latter, then perhaps I can use msleep_interruptible(). If you > only wish to sleep until a signal is received (or the timeout occurs) then > msleep_interruptible() may be a valid choice. > > Please let me know what you think. >From my experience, there's also a side effect of using UNINTERRUPTIBLE, which is that your sleep time gets counted as load in the loadavg. In the case of a kernel thread that don't do signals and need to pop up regulary, it's best to use INTERRUPTIBLE after making sure all signals are blocked. Ben. From zwane at fsmlabs.com Tue Dec 21 06:16:02 2004 From: zwane at fsmlabs.com (Zwane Mwaikambo) Date: Mon, 20 Dec 2004 12:16:02 -0700 (MST) Subject: [PATCH] Fix hotplug cpu on ppc64 Message-ID: I seem to have broken this when i moved the clearing of the dying cpu to arch specific code. Signed-off-by: Zwane Mwaikambo Index: linux-2.6.10-rc3-mm1/arch/ppc64/kernel/pSeries_smp.c =================================================================== RCS file: /home/cvsroot/linux-2.6.10-rc3-mm1/arch/ppc64/kernel/pSeries_smp.c,v retrieving revision 1.1.1.1 diff -u -p -B -r1.1.1.1 pSeries_smp.c --- linux-2.6.10-rc3-mm1/arch/ppc64/kernel/pSeries_smp.c 13 Dec 2004 14:26:53 -0000 1.1.1.1 +++ linux-2.6.10-rc3-mm1/arch/ppc64/kernel/pSeries_smp.c 20 Dec 2004 19:12:02 -0000 @@ -92,11 +92,13 @@ int __cpu_disable(void) { /* FIXME: go put this in a header somewhere */ extern void xics_migrate_irqs_away(void); + int cpu = smp_processor_id(); + cpu_clear(cpu, cpu_online_map); systemcfg->processorCount--; /*fix boot_cpuid here*/ - if (smp_processor_id() == boot_cpuid) + if (cpu == boot_cpuid) boot_cpuid = any_online_cpu(cpu_online_map); /* FIXME: abstract this to not be platform specific later on */ From nacc at us.ibm.com Tue Dec 21 11:25:13 2004 From: nacc at us.ibm.com (Nishanth Aravamudan) Date: Mon, 20 Dec 2004 16:25:13 -0800 Subject: {rtasd,rtc,scanlog}.c schedule_timeout() usage In-Reply-To: <1103359295.17734.6.camel@gaston> References: <20041218005445.GE2397@us.ibm.com> <1103359295.17734.6.camel@gaston> Message-ID: <20041221002513.GE2466@us.ibm.com> On Sat, Dec 18, 2004 at 09:41:35AM +0100, Benjamin Herrenschmidt wrote: > On Fri, 2004-12-17 at 16:54 -0800, Nishanth Aravamudan wrote: > > Hi, > > > > I'm trying to work some more on auditing the usage of schedule_timeout(), > > replacing most calls with either msleep() or msleep_interruptible(), depending > > on the state to sleep in. I am now begginning to replace code outside of drivers > > and came across arch/ppc64/kernel/{rtc,rtasd,scanlog}.c, all of which use > > TASK_INTERRUPTIBLE schedule_timeout() calls. > > > > My understand, though, is that TASK_INTERRUPTIBLE directly indicates that one > > should be able to handle waking up early if a signal is received. I don't see > > any signal handling / responding in the code around these timeouts. Would > > TASK_UNINTERRUPTIBLE work in these cases (indicating sleeping for waitqueue > > events (which I don't see around the code, so I'm guessing means an absolute > > sleep). If the latter, then perhaps I can use msleep_interruptible(). If you > > only wish to sleep until a signal is received (or the timeout occurs) then > > msleep_interruptible() may be a valid choice. > > > > Please let me know what you think. > > >From my experience, there's also a side effect of using UNINTERRUPTIBLE, > which is that your sleep time gets counted as load in the loadavg. In > the case of a kernel thread that don't do signals and need to pop up > regulary, it's best to use INTERRUPTIBLE after making sure all signals > are blocked. It seems to me, though, that if you really don't want to deal with signals & you really intend to sleep the full second (in rtasd.c, for instance), then it makes perfect sense to use TASK_UNINTERRUPTIBLE (i.e. msleep). Yes it will count to loadavg, but that doesn't mean the code is wrong (maybe the calculation of loadavg is incorrect?). Because the only the thing the task is doing in TASK_UNINTERRUPTIBLE is doing is sleeping. Meaning that while loadavg may go up (by 1 for each TASK_UNINTERRUPTIBLE task?), the CPU stays at idle. I would like more input, definitely. Thanks, Nish From nacc at us.ibm.com Tue Dec 21 11:36:27 2004 From: nacc at us.ibm.com (Nishanth Aravamudan) Date: Mon, 20 Dec 2004 16:36:27 -0800 Subject: {rtasd,rtc,scanlog}.c schedule_timeout() usage In-Reply-To: <1103359295.17734.6.camel@gaston> References: <20041218005445.GE2397@us.ibm.com> <1103359295.17734.6.camel@gaston> Message-ID: <20041221003627.GF2466@us.ibm.com> On Sat, Dec 18, 2004 at 09:41:35AM +0100, Benjamin Herrenschmidt wrote: > On Fri, 2004-12-17 at 16:54 -0800, Nishanth Aravamudan wrote: > > Hi, > > > > I'm trying to work some more on auditing the usage of schedule_timeout(), > > replacing most calls with either msleep() or msleep_interruptible(), depending > > on the state to sleep in. I am now begginning to replace code outside of drivers > > and came across arch/ppc64/kernel/{rtc,rtasd,scanlog}.c, all of which use > > TASK_INTERRUPTIBLE schedule_timeout() calls. > > > > My understand, though, is that TASK_INTERRUPTIBLE directly indicates that one > > should be able to handle waking up early if a signal is received. I don't see > > any signal handling / responding in the code around these timeouts. Would > > TASK_UNINTERRUPTIBLE work in these cases (indicating sleeping for waitqueue > > events (which I don't see around the code, so I'm guessing means an absolute > > sleep). If the latter, then perhaps I can use msleep_interruptible(). If you > > only wish to sleep until a signal is received (or the timeout occurs) then > > msleep_interruptible() may be a valid choice. > > > > Please let me know what you think. > > >From my experience, there's also a side effect of using UNINTERRUPTIBLE, > which is that your sleep time gets counted as load in the loadavg. In > the case of a kernel thread that don't do signals and need to pop up > regulary, it's best to use INTERRUPTIBLE after making sure all signals > are blocked. Also, I just noticed that rtc.c calls rtas_extended_busy_delay_time() to calculate the time to sleep. It seems that this function takes as parameter an order value, and calculates a delay of 10^n milliseconds (per the comment). But then there is another comment claiming to use microseconds as the units. Finally (regardless of this units issue), the calculated delay is returned and used as the parameter to schedule_timeout(). This is clearly incorrect logic (even if correct code currently), though, as it relies on jiffies being the equivalent of one of these time units. Does anyone know what units this value should have? Thanks, Nish From anton at samba.org Tue Dec 21 11:55:35 2004 From: anton at samba.org (Anton Blanchard) Date: Tue, 21 Dec 2004 11:55:35 +1100 Subject: {rtasd,rtc,scanlog}.c schedule_timeout() usage In-Reply-To: <20041221002513.GE2466@us.ibm.com> References: <20041218005445.GE2397@us.ibm.com> <1103359295.17734.6.camel@gaston> <20041221002513.GE2466@us.ibm.com> Message-ID: <20041221005535.GB29187@krispykreme.ozlabs.ibm.com> Hi, > It seems to me, though, that if you really don't want to deal with > signals & you really intend to sleep the full second (in rtasd.c, for > instance), then it makes perfect sense to use TASK_UNINTERRUPTIBLE > (i.e. msleep). Yes it will count to loadavg, but that doesn't mean the > code is wrong (maybe the calculation of loadavg is incorrect?). > Because the only the thing the task is doing in TASK_UNINTERRUPTIBLE > is doing is sleeping. Meaning that while loadavg may go up (by 1 for > each TASK_UNINTERRUPTIBLE task?), the CPU stays at idle. I agree we dont want to handle signals but having an idle machine at a load average of 1 would be confusing. Anton From nacc at us.ibm.com Tue Dec 21 12:20:17 2004 From: nacc at us.ibm.com (Nishanth Aravamudan) Date: Mon, 20 Dec 2004 17:20:17 -0800 Subject: {rtasd,rtc,scanlog}.c schedule_timeout() usage In-Reply-To: <20041221005535.GB29187@krispykreme.ozlabs.ibm.com> References: <20041218005445.GE2397@us.ibm.com> <1103359295.17734.6.camel@gaston> <20041221002513.GE2466@us.ibm.com> <20041221005535.GB29187@krispykreme.ozlabs.ibm.com> Message-ID: <20041221012017.GG2466@us.ibm.com> On Tue, Dec 21, 2004 at 11:55:35AM +1100, Anton Blanchard wrote: > > Hi, > > > It seems to me, though, that if you really don't want to deal with > > signals & you really intend to sleep the full second (in rtasd.c, for > > instance), then it makes perfect sense to use TASK_UNINTERRUPTIBLE > > (i.e. msleep). Yes it will count to loadavg, but that doesn't mean the > > code is wrong (maybe the calculation of loadavg is incorrect?). > > Because the only the thing the task is doing in TASK_UNINTERRUPTIBLE > > is doing is sleeping. Meaning that while loadavg may go up (by 1 for > > each TASK_UNINTERRUPTIBLE task?), the CPU stays at idle. > > I agree we dont want to handle signals but having an idle machine at > a load average of 1 would be confusing. Hmm, would you prefer then, having the code block all signals before (and then restoring them after) the sleep? -Nish From j.glisse at free.fr Fri Dec 24 22:37:34 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Fri, 24 Dec 2004 12:37:34 +0100 Subject: R300 powerpc & agp Message-ID: <41CBFF7E.4090105@free.fr> Hi, I wanted to test the r300 demo on powerpc to see if i can make it working unfortunetly i only have a too recent mac for having agp support. My device id (for agp bridge is 0059) i tested it with a 2.6.10-rc3 anysupport soon for this chipset ? Does the darwin source give anyclue on it :) The mac is a dual 2G (lastest revision i guess). By the way the fan control work well over here, thx Benjamin. best, Jerome Glisse From benh at kernel.crashing.org Sat Dec 25 01:54:31 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Fri, 24 Dec 2004 15:54:31 +0100 Subject: R300 powerpc & agp In-Reply-To: <41CBFF7E.4090105@free.fr> References: <41CBFF7E.4090105@free.fr> Message-ID: <1103900072.25875.8.camel@gaston> On Fri, 2004-12-24 at 12:37 +0100, Jerome Glisse wrote: > Hi, > > I wanted to test the r300 demo on powerpc to see if i can make > it working unfortunetly i only have a too recent mac for having > agp support. > > My device id (for agp bridge is 0059) i tested it with a 2.6.10-rc3 > anysupport soon for this chipset ? Does the darwin source give > anyclue on it :) The mac is a dual 2G (lastest revision i guess). > > By the way the fan control work well over here, thx Benjamin. I think the u3 AGP interface is very similar to the previous one as far as the GART setup is concerned, I don't remember if the x8 mode introduces differences though. The Darwin source for Apple driver is available (AppleMacRISCPCI-2 project), so you should be able to spot the differences there. Ben. From j.glisse at free.fr Sat Dec 25 03:39:19 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Fri, 24 Dec 2004 17:39:19 +0100 Subject: U3 AGP Message-ID: <41CC4637.8020301@free.fr> Hi, Still looking in U3 agp i found something strange in uninorth-agp.c for function static void uninorth_tlbflush(struct agp_memory *mem) { pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_INVAL); pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, UNI_N_CFG_GART_ENABLE); pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_2xRESET); pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, UNI_N_CFG_GART_ENABLE); } the arg mem is not used, shouldn't it be used to write something like : static void uninorth_tlbflush(struct agp_memory *mem) { pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_INVAL); pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, UNI_N_CFG_GART_ENABLE); // Here write what is in mem :) pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, UNI_N_CFG_GART_ENABLE | UNI_N_CFG_GART_2xRESET); pci_write_config_dword(agp_bridge->dev, UNI_N_CFG_GART_CTRL, UNI_N_CFG_GART_ENABLE); } Or maybe flush_dcache_range is already doing the job before this function get called so i guess uninorth_tlbflush do not need to have any clue of mem. Moreover it looks like that apple is no more using this way to flush in lastest darwin AppleMacRISCPCI-2 it is commented out (maybe they have move it elsewhere). best, Jerome Glisse From j.glisse at free.fr Sat Dec 25 06:05:04 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Fri, 24 Dec 2004 20:05:04 +0100 Subject: radeon drm/dri Message-ID: <41CC6860.7040300@free.fr> Sorry for cross posting but i am not confident on the origin of my bug. Right now i am playing with agp support for G5 and i got nothing else than X.org & DRI for testing. I success in getting X starting & claiming that he has no problem and i see the cursor and the normal background of X but then the X server start to grow is processor use until max. The box is still alive as i can ssh in. So my question is there any issue with Xorg/DRI/DRM on mac i see Benjamin sending patch not so long but i have not checked if they were in my Xorg version (cvs checkout from yesterday for Xorg & drm). If DRI/DRM is not broken then i guess this is because i doing something wrong with my agp code. Is there is way to test agp other than using DRI/DRM so i can work without killing my X every 5min :) ? By the way there have been some change between old uninorth and new one. best, Jerome Glisse From michel at daenzer.net Sat Dec 25 14:35:58 2004 From: michel at daenzer.net (Michel =?ISO-8859-1?Q?D=E4nzer?=) Date: Fri, 24 Dec 2004 22:35:58 -0500 Subject: radeon drm/dri In-Reply-To: <41CC6860.7040300@free.fr> References: <41CC6860.7040300@free.fr> Message-ID: <1103945758.5369.66.camel@thor.asgaard.local> On Fri, 2004-12-24 at 20:05 +0100, Jerome Glisse wrote: > > Right now i am playing with agp support for G5 and i got nothing else than > X.org & DRI for testing. I success in getting X starting & claiming that > he has no problem and i see the cursor and the normal background of X > but then the X server start to grow is processor use until max. The box > is still alive as i can ssh in. > > So my question is there any issue with Xorg/DRI/DRM on mac i see Benjamin > sending patch not so long but i have not checked if they were in my Xorg > version (cvs checkout from yesterday for Xorg & drm). If DRI/DRM is not > broken then i guess this is because i doing something wrong with my agp > code. That's more likely indeed. You should be able to verify that with Option "BusType" "PCI" > Is there is way to test agp other than using DRI/DRM so i can work without > killing my X every 5min :) ? I'm not sure any AGP functionality can be exercised in a hardware independent way. There used to be a drmtest.c file in the Mesa tree, don't know what happened to it. There's also a tests directory in the drm tree, but I'm not sure how useful that is for your purposes. It sounds like you may be in a good position to write a good test though? :) -- Earthling Michel D?nzer | Debian (powerpc), X and DRI developer Libre software enthusiast | http://svcs.affero.net/rm.php?r=daenzer From j.glisse at free.fr Sun Dec 26 02:58:17 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Sat, 25 Dec 2004 16:58:17 +0100 Subject: DRI R300 corrupted display purely DRI issue ? G5 AGP support Message-ID: <41CD8E19.2050401@free.fr> Hi, So i get my G5 AGP working but i get a corrupted display like Keith Conger reported no so long on one of this mailing list. My question is anybody working on it ? If no i will try to correct this but i fear that now i will have less time to spend on R300 (for the next month). Anyway you can grab a screenshot here : http://dj.planet-d.net/Capture.png As Vladimir said this must be related to an endian issue... Between Michael Option "BusType" "PCI" is not working properly (drm refuse to do any mapping but this must be related to r300 drm not r200 ?) I also see this in my syslog : Dec 25 16:25:33 localhost kernel: [drm:radeon_cp_init] *ERROR* radeon_cp_init called without lock held Dec 25 16:25:33 localhost kernel: [drm:radeon_unlock] *ERROR* Process 2460 using kernel context 0 R300 related too ? Now PPC stuff :) For adding support to G5 i have to add some values & device id but i am not sure on the proper naming for them. Below what i choose : include/linux/pci_ids.h #define PCI_DEVICE_ID_APPLE_UNI_N_AGP8 0x0059 Maybe i better use : #define PCI_DEVICE_ID_APPLE_UNI_N_AGP3 0x0059 as it seems that this is an AGP3 controller. I need to add this to include/asm/uninorth.h this seems to be only used by AGP3 uninorth G5 controller. This values came from darwin, their names too. I am only using PERFRD at the moment but others maybe usefull latter if we had features like fastwrite. #define UNI_N_CFG_GART_SYNCMODE 0x00040000 #define UNI_N_CFG_GART_PERFRD 0x00080000 #define UNI_N_CFG_GART_B2BGNT 0x00200000 #define UNI_N_CFG_GART_FASTDDR 0x00400000 I use a magic value (not so magic thought :)) 12 which correspond to PAGE_SHIFT in darwin this value depend on page size. Is there any equivalent infos in linux ? For the moment i use a hardcoded value. I changed uninorth_tbl_flush, uninorth_cleanup, uninorth_insert_memory, uninorth_agp_enable So, i am wondering if it's not better to have a different driver like uninorth3 (for AGP3) instead of having test to see if we have a G5 agp or an older one in each functions. Moreover maybe more of the generic version of agp3(drivers/char/agp/generic.c) could be used. Any comment on this would be appreciated. best, Jerome Glisse From domen at coderock.org Sun Dec 26 04:45:34 2004 From: domen at coderock.org (domen at coderock.org) Date: Sat, 25 Dec 2004 18:45:34 +0100 Subject: [patch 2/2] delete unused file Message-ID: <20041225174524.4CDDA1EA0F@trashy.coderock.org> Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer --- kj/include/asm-ppc64/iSeries/iSeries_fixup.h | 25 ------------------------- 1 files changed, 25 deletions(-) diff -L include/asm-ppc64/iSeries/iSeries_fixup.h -puN include/asm-ppc64/iSeries/iSeries_fixup.h~remove_file-include_asm_ppc64_iSeries_iSeries_fixup.h /dev/null --- kj/include/asm-ppc64/iSeries/iSeries_fixup.h +++ /dev/null 2004-12-24 01:21:08.000000000 +0100 @@ -1,25 +0,0 @@ - -#ifndef __ISERIES_FIXUP_H__ -#define __ISERIES_FIXUP_H__ -#include - -#ifdef __cplusplus -extern "C" { -#endif - -void iSeries_fixup (void); -void iSeries_fixup_bus (struct pci_bus*); -unsigned int iSeries_scan_slot (struct pci_dev*, u16, u8, u8); - - -/* Need to store information related to the PHB bucc and make it accessible to the hose */ -struct iSeries_hose_arch_data { - u32 hvBusNumber; -}; - - -#ifdef __cplusplus -} -#endif - -#endif /* __ISERIES_FIXUP_H__ */ _ From domen at coderock.org Sun Dec 26 04:45:31 2004 From: domen at coderock.org (domen at coderock.org) Date: Sat, 25 Dec 2004 18:45:31 +0100 Subject: [patch 1/2] delete unused file Message-ID: <20041225174521.579D91EA0F@trashy.coderock.org> Remove nowhere referenced file. (egrep "filename\." didn't find anything) Signed-off-by: Domen Puncer --- kj/arch/ppc64/boot/no_initrd.c | 2 -- 1 files changed, 2 deletions(-) diff -L arch/ppc64/boot/no_initrd.c -puN arch/ppc64/boot/no_initrd.c~remove_file-arch_ppc64_boot_no_initrd.c /dev/null --- kj/arch/ppc64/boot/no_initrd.c +++ /dev/null 2004-12-24 01:21:08.000000000 +0100 @@ -1,2 +0,0 @@ -char initrd_data[1]; -int initrd_len = 0; _ From j.glisse at free.fr Sun Dec 26 08:19:54 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Sat, 25 Dec 2004 22:19:54 +0100 Subject: G5 AGP Message-ID: <41CDD97A.10702@free.fr> Hi, I am working on G5 agp uninorth and i am facing a strange problem. I have my agpworking but the change i made seems to broke the fan control, thus the fan start to go to their full speed shortly after i load my uninorth driver. Is fan control related in anyway to PCI or AGP ? :) By the way i could not unload my module, kernel claim that is used by someone even if no one (no graphics card module loaded) any clue ? best, Jerome Glisse From benh at kernel.crashing.org Sun Dec 26 21:00:02 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 26 Dec 2004 11:00:02 +0100 Subject: G5 AGP In-Reply-To: <41CDD97A.10702@free.fr> References: <41CDD97A.10702@free.fr> Message-ID: <1104055202.23891.10.camel@gaston> On Sat, 2004-12-25 at 22:19 +0100, Jerome Glisse wrote: > Hi, > > I am working on G5 agp uninorth and i am facing a strange problem. > I have my agpworking but the change i made seems to broke the fan > control, thus the fan start to go to their full speed shortly after i load > my uninorth driver. > > Is fan control related in anyway to PCI or AGP ? :) No, that's weird. All fans are ramping up or only the backside one ? You could enable the debug output in the fan driver... > By the way i could not unload my module, kernel claim that is used > by someone even if no one (no graphics card module loaded) any clue ? Probably the AGP core From benh at kernel.crashing.org Sun Dec 26 21:02:59 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Sun, 26 Dec 2004 11:02:59 +0100 Subject: DRI R300 corrupted display purely DRI issue ? G5 AGP support In-Reply-To: <41CD8E19.2050401@free.fr> References: <41CD8E19.2050401@free.fr> Message-ID: <1104055379.5615.13.camel@gaston> > include/linux/pci_ids.h > #define PCI_DEVICE_ID_APPLE_UNI_N_AGP8 0x0059 > Maybe i better use : > #define PCI_DEVICE_ID_APPLE_UNI_N_AGP3 0x0059 > as it seems that this is an AGP3 controller. Call it PCI_DEVICE_ID_APPLE_U3_AGP > I need to add this to include/asm/uninorth.h this seems to > be only used by AGP3 uninorth G5 controller. This values > came from darwin, their names too. I am only using PERFRD > at the moment but others maybe usefull latter if we had features > like fastwrite. > > #define UNI_N_CFG_GART_SYNCMODE 0x00040000 > #define UNI_N_CFG_GART_PERFRD 0x00080000 > #define UNI_N_CFG_GART_B2BGNT 0x00200000 > #define UNI_N_CFG_GART_FASTDDR 0x00400000 > > I use a magic value (not so magic thought :)) 12 which correspond > to PAGE_SHIFT in darwin this value depend on page size. Is there > any equivalent infos in linux ? For the moment i use a hardcoded value. PAGE_SHIFT for now should be fine. If we change the CPU page size, I'll have to fix the driver anyway. > I changed uninorth_tbl_flush, uninorth_cleanup, > uninorth_insert_memory, uninorth_agp_enable > > So, i am wondering if it's not better to have a different driver > like uninorth3 (for AGP3) instead of having test to see if we have > a G5 agp or an older one in each functions. Moreover maybe more > of the generic version of agp3(drivers/char/agp/generic.c) could be used. If they end up to be different enough, yes, make a u3-agp driver separate. I don't think much of the generic stuff can be used. > Any comment on this would be appreciated. > > best, > Jerome Glisse > _______________________________________________ > Linuxppc64-dev mailing list > Linuxppc64-dev at ozlabs.org > https://ozlabs.org/cgi-bin/mailman/listinfo/linuxppc64-dev -- Benjamin Herrenschmidt From j.glisse at free.fr Mon Dec 27 01:12:00 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Sun, 26 Dec 2004 15:12:00 +0100 Subject: PATCH uninorth3 (G5) agp support Message-ID: <41CEC6B0.5020106@free.fr> Here's a patch which adds AGP support to i think all G5 at least uninorth3 chipset. If you could test it even if i am quite confident there is no bug in it :) I also cleaned up a bit the old uninorth by using PAGE_SHIFT, PAGE_MASK and other defined macro where they shoud have been used. Ben i corrected the issue i got with fan, i was writting some wrong magic in wrong place. So you should have agp enable with this patch, thus if anyone with a g5 & r200 would test the dri to see if it could successfull use the agp for the video card. Anyother way to test it ? If you use Xorg you may need to add this to your conf file if you see that you font are corrupted (it seems there is a bug somewhere in dri) Option "XaaNoScanlineImageWriteRect" best, Jerome Glisse -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uninorth-patch Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041226/e4e78551/attachment.txt From benh at kernel.crashing.org Mon Dec 27 19:52:06 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 27 Dec 2004 09:52:06 +0100 Subject: PATCH uninorth3 (G5) agp support In-Reply-To: <41CEC6B0.5020106@free.fr> References: <41CEC6B0.5020106@free.fr> Message-ID: <1104137527.5615.20.camel@gaston> > +/* The following seems to only be used only on U3 */ > +#define UNI_N_CFG_GART_SYNCMODE 0x00040000 > +#define UNI_N_CFG_GART_PERFRD 0x00080000 > +#define UNI_N_CFG_GART_B2BGNT 0x00200000 > +#define UNI_N_CFG_GART_FASTDDR 0x00400000 Please, call them U3_* > /* My understanding of UniNorth AGP as of UniNorth rev 1.0x, > * revision 1.5 (x4 AGP) may need further changes. > diff -Naur linux/include/linux/pci_ids.h linux-new/include/linux/pci_ids.h > --- linux/include/linux/pci_ids.h 2004-12-26 14:40:05.000000000 +0100 > +++ linux-new/include/linux/pci_ids.h 2004-12-26 14:50:19.000000000 +0100 > @@ -842,6 +842,7 @@ > #define PCI_DEVICE_ID_APPLE_UNI_N_GMAC2 0x0032 > #define PCI_DEVIEC_ID_APPLE_UNI_N_ATA 0x0033 > #define PCI_DEVICE_ID_APPLE_UNI_N_AGP2 0x0034 > +#define PCI_DEVICE_ID_APPLE_UNI_N_AGP3 0x0059 > #define PCI_DEVICE_ID_APPLE_IPID_ATA100 0x003b > #define PCI_DEVICE_ID_APPLE_KEYLARGO_I 0x003e > #define PCI_DEVICE_ID_APPLE_K2_ATA100 0x0043 Plase, call it PCI_DEVICE_ID_APPLE_U3_AGP The name of the chip is not "UniNorth 3" but "U3" :) (Same goes with U2 btw). Ben. From benh at kernel.crashing.org Mon Dec 27 19:50:05 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 27 Dec 2004 09:50:05 +0100 Subject: PATCH uninorth3 (G5) agp support In-Reply-To: <41CEC6B0.5020106@free.fr> References: <41CEC6B0.5020106@free.fr> Message-ID: <1104137405.5615.17.camel@gaston> > + if((uninorth_rev >= 0x30) && (uninorth_rev <= 0x33)) { > + /* > + * We need to to set REQ_DEPTH to 7 for U3 versions 1.0, 2.1, > + * 2.2 and 2.3, Darwin do so. > + */ > + command |= (7 << AGPSTAT_RQ_DEPTH_SHIFT); > + } > Some revs of U3 (3.x) do have some high bits sets in the version register, you should probably mask it with 0x3f ... Though on the other hand, I don't know if revisions prior to 3.x were ever used on production... Ben. From j.glisse at free.fr Mon Dec 27 10:45:58 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Mon, 27 Dec 2004 00:45:58 +0100 Subject: PATCH uninorth3 (G5) agp support (V2) Message-ID: <41CF4D36.1020601@free.fr> Oops i forgot to enable AGP V3 on uninorth3 thus here is the patch with this (forget the old patch) but you should read my mail as i describe a bit the patch & ask for testing. best, Jerome Glisse -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uninorth-patch2 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041227/c69adee4/attachment.txt From j.glisse at free.fr Mon Dec 27 23:51:48 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Mon, 27 Dec 2004 13:51:48 +0100 Subject: PATCH uninorth3 (G5) agp support In-Reply-To: <1104137527.5615.20.camel@gaston> References: <41CEC6B0.5020106@free.fr> <1104137527.5615.20.camel@gaston> Message-ID: <41D00564.6010507@free.fr> I changed the name to proper one :) And masked the rev version, Darwin do so to even if it is unlikely that such revision have been used for production. thanx for your comments, will you push it too the kernel (after testing) or do i have to send it elsewhere ? :) Anyway this is not a critical issue but if we manage to make the r300 chipset working (even only for 2d accel) than this could be usefull for users :) best, Jerome Glisse -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: uninorth-patch3 Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041227/ca48aaaf/attachment.txt From benh at kernel.crashing.org Tue Dec 28 00:32:00 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 27 Dec 2004 14:32:00 +0100 Subject: PATCH uninorth3 (G5) agp support In-Reply-To: <41D00564.6010507@free.fr> References: <41CEC6B0.5020106@free.fr> <1104137527.5615.20.camel@gaston> <41D00564.6010507@free.fr> Message-ID: <1104154320.23891.27.camel@gaston> On Mon, 2004-12-27 at 13:51 +0100, Jerome Glisse wrote: > I changed the name to proper one :) And masked > the rev version, Darwin do so to even if it is unlikely > that such revision have been used for production. Good ! > thanx for your comments, will you push it too the kernel. > (after testing) or doI i have to send it elsewhere ? :) Nah, I'll take care of it when I'm back from vacation. > Anyway this is not a critical issue but if we manage to > make the r300 chipset working (even only for 2d accel) > than this could be usefull for users :) Sure. There is still a pending issue though with AGP on the G5. The problem is that we create a non-cacheable mapping for the RAM pages of the AGP aperture (both in-kernel and for userland) while they already have a cacheable mapping via the normal kernel linear mapping of main memory. The result is that there is a potential cache aliasing issue, aggravated by the fact that the G5 is quite aggressive on pre-fetching and thuis, may end up prefetching some of the AGP cache lines (via the linear mapping) even if no actual access is ever done to these pages. Unfortunately, if a collision occurs (a non-cacheable access to some space that do exist in the cache at the same time), the result is undefined, and is likely to result in a checkstop (the CPU just stops). I really don't know of a simple remedy at this point. The problem is partially due to the fact that we do the linear mapping using large pages, so we can't simply undo the cacheable mapping for the pages that ended up beeing allocated for AGP... An option would be to eventually reserve the AGP memory early during boot and not include it in the linear mapping at all. Another thing to test is that maybe U3 is smart enough to snoop AGP accesses, and thus we could have the AGP mappings be cacheable as well (though that may require some stronger synchronisation directives in the DRM code). Ben. From j.glisse at free.fr Tue Dec 28 00:50:01 2004 From: j.glisse at free.fr (Jerome Glisse) Date: Mon, 27 Dec 2004 14:50:01 +0100 Subject: PATCH uninorth3 (G5) agp support In-Reply-To: <1104154320.23891.27.camel@gaston> References: <41CEC6B0.5020106@free.fr> <1104137527.5615.20.camel@gaston> <41D00564.6010507@free.fr> <1104154320.23891.27.camel@gaston> Message-ID: <41D01309.3000304@free.fr> >Sure. There is still a pending issue though with AGP on the G5. The >problem is that we create a non-cacheable mapping for the RAM pages of >the AGP aperture (both in-kernel and for userland) while they already >have a cacheable mapping via the normal kernel linear mapping of main >memory. > >The result is that there is a potential cache aliasing issue, aggravated >by the fact that the G5 is quite aggressive on pre-fetching and thuis, >may end up prefetching some of the AGP cache lines (via the linear >mapping) even if no actual access is ever done to these pages. > >Unfortunately, if a collision occurs (a non-cacheable access to some >space that do exist in the cache at the same time), the result is >undefined, and is likely to result in a checkstop (the CPU just stops). > >I really don't know of a simple remedy at this point. The problem is >partially due to the fact that we do the linear mapping using large >pages, so we can't simply undo the cacheable mapping for the pages that >ended up beeing allocated for AGP... An option would be to eventually >reserve the AGP memory early during boot and not include it in the >linear mapping at all. Another thing to test is that maybe U3 is smart >enough to snoop AGP accesses, and thus we could have the AGP mappings be >cacheable as well (though that may require some stronger synchronisation >directives in the DRM code). > >Ben. > > I got some lockup after adding agp support but i don't know if it came from my playing with the r300 (most probable source :)) or from the cache collision you are talking about. Anyway it's not time to think to that :) Have good hollydays. I will look a bit further in this to see if i can find anythings that may helps. best, Jerome Glisse From benh at kernel.crashing.org Tue Dec 28 00:52:43 2004 From: benh at kernel.crashing.org (Benjamin Herrenschmidt) Date: Mon, 27 Dec 2004 14:52:43 +0100 Subject: PATCH uninorth3 (G5) agp support In-Reply-To: <41D01309.3000304@free.fr> References: <41CEC6B0.5020106@free.fr> <1104137527.5615.20.camel@gaston> <41D00564.6010507@free.fr> <1104154320.23891.27.camel@gaston> <41D01309.3000304@free.fr> Message-ID: <1104155563.23891.29.camel@gaston> > I got some lockup after adding agp support but i don't know if > it came from my playing with the r300 (most probable > source :)) or from the cache collision you are talking about. > > Anyway it's not time to think to that :) Have good hollydays. > > I will look a bit further in this to see if i can find anythings > that may helps. One possiblily to fix the potential issue of cache collision would be to steal the AGP pages from the hugetlb pool (large pages) instead of small 4k pages. This would make it possible to unmap them individually from the kernel linear mapping... Ben. From solrac at us.ibm.com Tue Dec 28 11:42:16 2004 From: solrac at us.ibm.com (Frank Carlos) Date: Mon, 27 Dec 2004 16:42:16 -0800 Subject: News Tip: Great moments in microprocessor history Message-ID: Great moments in microprocessor history The microprocessor changed the world: how did we get from the first 4-bit models in the 1970s to today's 64-bit multicore monsters? This article covers the history of the micro from the vacuum tube to today's dual-core multithreaded madnes. Kind regards, Frank From nathanl at austin.ibm.com Thu Dec 30 15:33:26 2004 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Wed, 29 Dec 2004 22:33:26 -0600 Subject: [PATCH] sparse fixes for cpu feature constants Message-ID: <1104381206.16694.38.camel@localhost.localdomain> Hi- I've been playing around with sparse a little and saw that it gives a lot of warnings like this: arch/ppc64/mm/init.c:755:35: warning: constant 0x0000020000000000 is so big it is long It looks like we get such a warning for every expression of the form "(cur_cpu_spec->cpu_features & CPU_FTR_COHERENT_ICACHE)" -- basically, every time the code checks for a cpu feature. Following is an attempt to clean these up by defining the cpu feature constants using the ASM_CONST macro from ppc64's page.h. I believe this is consistent with the intentions for ASM_CONST's use. There's some fallout: flush_icache_range() was already using ASM_CONST on one of the constants, so that is fixed up. switch_mm() uses a BEGIN_FTR_SECTION ... END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) which gets broken by the change since 0x0000000000000008UL winds up in the generated assembly. I couldn't find the BEGIN/END_FTR_SECTION construct used in any other C code, so I replaced this with the usual bitwise 'and' conditional (I hope someone else will verify that this is equivalent :). So, does this look like the right thing to do? It eliminates 129 sparse warnings from a defconfig 2.6.10 build. Signed-off-by: Nathan Lynch Index: 2.6.10/include/asm-ppc64/cputable.h =================================================================== --- 2.6.10.orig/include/asm-ppc64/cputable.h 2004-12-24 21:35:23.000000000 +0000 +++ 2.6.10/include/asm-ppc64/cputable.h 2004-12-30 04:04:09.463979408 +0000 @@ -16,6 +16,7 @@ #define __ASM_PPC_CPUTABLE_H #include +#include /* for ASM_CONST */ /* Exposed to userland CPU features - Must match ppc32 definitions */ #define PPC_FEATURE_32 0x80000000 @@ -103,38 +104,38 @@ /* CPU kernel features */ /* Retain the 32b definitions for the time being - use bottom half of word */ -#define CPU_FTR_SPLIT_ID_CACHE 0x0000000000000001 -#define CPU_FTR_L2CR 0x0000000000000002 -#define CPU_FTR_SPEC7450 0x0000000000000004 -#define CPU_FTR_ALTIVEC 0x0000000000000008 -#define CPU_FTR_TAU 0x0000000000000010 -#define CPU_FTR_CAN_DOZE 0x0000000000000020 -#define CPU_FTR_USE_TB 0x0000000000000040 -#define CPU_FTR_604_PERF_MON 0x0000000000000080 -#define CPU_FTR_601 0x0000000000000100 -#define CPU_FTR_HPTE_TABLE 0x0000000000000200 -#define CPU_FTR_CAN_NAP 0x0000000000000400 -#define CPU_FTR_L3CR 0x0000000000000800 -#define CPU_FTR_L3_DISABLE_NAP 0x0000000000001000 -#define CPU_FTR_NAP_DISABLE_L2_PR 0x0000000000002000 -#define CPU_FTR_DUAL_PLL_750FX 0x0000000000004000 +#define CPU_FTR_SPLIT_ID_CACHE ASM_CONST(0x0000000000000001) +#define CPU_FTR_L2CR ASM_CONST(0x0000000000000002) +#define CPU_FTR_SPEC7450 ASM_CONST(0x0000000000000004) +#define CPU_FTR_ALTIVEC ASM_CONST(0x0000000000000008) +#define CPU_FTR_TAU ASM_CONST(0x0000000000000010) +#define CPU_FTR_CAN_DOZE ASM_CONST(0x0000000000000020) +#define CPU_FTR_USE_TB ASM_CONST(0x0000000000000040) +#define CPU_FTR_604_PERF_MON ASM_CONST(0x0000000000000080) +#define CPU_FTR_601 ASM_CONST(0x0000000000000100) +#define CPU_FTR_HPTE_TABLE ASM_CONST(0x0000000000000200) +#define CPU_FTR_CAN_NAP ASM_CONST(0x0000000000000400) +#define CPU_FTR_L3CR ASM_CONST(0x0000000000000800) +#define CPU_FTR_L3_DISABLE_NAP ASM_CONST(0x0000000000001000) +#define CPU_FTR_NAP_DISABLE_L2_PR ASM_CONST(0x0000000000002000) +#define CPU_FTR_DUAL_PLL_750FX ASM_CONST(0x0000000000004000) /* Add the 64b processor unique features in the top half of the word */ -#define CPU_FTR_SLB 0x0000000100000000 -#define CPU_FTR_16M_PAGE 0x0000000200000000 -#define CPU_FTR_TLBIEL 0x0000000400000000 -#define CPU_FTR_NOEXECUTE 0x0000000800000000 -#define CPU_FTR_NODSISRALIGN 0x0000001000000000 -#define CPU_FTR_IABR 0x0000002000000000 -#define CPU_FTR_MMCRA 0x0000004000000000 -#define CPU_FTR_PMC8 0x0000008000000000 -#define CPU_FTR_SMT 0x0000010000000000 -#define CPU_FTR_COHERENT_ICACHE 0x0000020000000000 -#define CPU_FTR_LOCKLESS_TLBIE 0x0000040000000000 -#define CPU_FTR_MMCRA_SIHV 0x0000080000000000 +#define CPU_FTR_SLB ASM_CONST(0x0000000100000000) +#define CPU_FTR_16M_PAGE ASM_CONST(0x0000000200000000) +#define CPU_FTR_TLBIEL ASM_CONST(0x0000000400000000) +#define CPU_FTR_NOEXECUTE ASM_CONST(0x0000000800000000) +#define CPU_FTR_NODSISRALIGN ASM_CONST(0x0000001000000000) +#define CPU_FTR_IABR ASM_CONST(0x0000002000000000) +#define CPU_FTR_MMCRA ASM_CONST(0x0000004000000000) +#define CPU_FTR_PMC8 ASM_CONST(0x0000008000000000) +#define CPU_FTR_SMT ASM_CONST(0x0000010000000000) +#define CPU_FTR_COHERENT_ICACHE ASM_CONST(0x0000020000000000) +#define CPU_FTR_LOCKLESS_TLBIE ASM_CONST(0x0000040000000000) +#define CPU_FTR_MMCRA_SIHV ASM_CONST(0x0000080000000000) /* Platform firmware features */ -#define FW_FTR_ 0x0000000000000001 +#define FW_FTR_ ASM_CONST(0x0000000000000001) #ifndef __ASSEMBLY__ #define COMMON_USER_PPC64 (PPC_FEATURE_32 | PPC_FEATURE_64 | \ Index: 2.6.10/include/asm-ppc64/cacheflush.h =================================================================== --- 2.6.10.orig/include/asm-ppc64/cacheflush.h 2004-12-24 21:33:51.000000000 +0000 +++ 2.6.10/include/asm-ppc64/cacheflush.h 2004-12-30 04:00:42.928965272 +0000 @@ -40,7 +40,7 @@ static inline void flush_icache_range(unsigned long start, unsigned long stop) { - if (!(cur_cpu_spec->cpu_features & ASM_CONST(CPU_FTR_COHERENT_ICACHE))) + if (!(cur_cpu_spec->cpu_features & CPU_FTR_COHERENT_ICACHE)) __flush_icache_range(start, stop); } Index: 2.6.10/include/asm-ppc64/mmu_context.h =================================================================== --- 2.6.10.orig/include/asm-ppc64/mmu_context.h 2004-12-24 21:34:31.000000000 +0000 +++ 2.6.10/include/asm-ppc64/mmu_context.h 2004-12-30 04:00:42.000000000 +0000 @@ -52,11 +52,8 @@ struct task_struct *tsk) { #ifdef CONFIG_ALTIVEC - asm volatile ( - BEGIN_FTR_SECTION - "dssall;\n" - END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) - : : ); + if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC) + asm volatile ("dssall;\n" : : ); #endif /* CONFIG_ALTIVEC */ if (!cpu_isset(smp_processor_id(), next->cpu_vm_mask)) From nathanl at austin.ibm.com Thu Dec 30 16:52:22 2004 From: nathanl at austin.ibm.com (Nathan Lynch) Date: Wed, 29 Dec 2004 23:52:22 -0600 Subject: [PATCH] sparse fixes for cpu feature constants In-Reply-To: <1104381206.16694.38.camel@localhost.localdomain> References: <1104381206.16694.38.camel@localhost.localdomain> Message-ID: <41D39796.6090403@austin.ibm.com> Nathan Lynch wrote: > --- 2.6.10.orig/include/asm-ppc64/mmu_context.h 2004-12-24 21:34:31.000000000 +0000 > +++ 2.6.10/include/asm-ppc64/mmu_context.h 2004-12-30 04:00:42.000000000 +0000 > @@ -52,11 +52,8 @@ > struct task_struct *tsk) > { > #ifdef CONFIG_ALTIVEC > - asm volatile ( > - BEGIN_FTR_SECTION > - "dssall;\n" > - END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC) > - : : ); > + if (cur_cpu_spec->cpu_features & CPU_FTR_ALTIVEC) > + asm volatile ("dssall;\n" : : ); > #endif /* CONFIG_ALTIVEC */ And my mail client mangled the patch... new one attached. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ppc64-sparse-fixes Url: http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20041229/18e7b9f3/attachment.txt