[MPC7448] machdep_calls
Hello, I am developping a Linux for my PPC Board. I must write a define_machine structure (marchdep_calls). Where can I find some Information about functions of this structure ? Thanx Sébastien Chrétien ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
On Mon, 2008-08-18 at 10:45 +0200, Sébastien Chrétien wrote: Hello, I am developping a Linux for my PPC Board. I must write a define_machine structure (marchdep_calls). Where can I find some Information about functions of this structure ? It isn't well documented unfortunately. Best is to look at what others do... and then find your way through. I agree somebody should write dome doco one day ... in the meantime, feel free to ask questions here. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
Ok I am going to copy some examples. 2008/8/18, Benjamin Herrenschmidt [EMAIL PROTECTED]: On Mon, 2008-08-18 at 10:45 +0200, Sébastien Chrétien wrote: Hello, I am developping a Linux for my PPC Board. I must write a define_machine structure (marchdep_calls). Where can I find some Information about functions of this structure ? It isn't well documented unfortunately. Best is to look at what others do... and then find your way through. I agree somebody should write dome doco one day ... in the meantime, feel free to ask questions here. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
Can somebody explain me the aim of the function setup_arch in the machine_call structure ? 2008/8/18, Sébastien Chrétien [EMAIL PROTECTED]: Ok I am going to copy some examples. 2008/8/18, Benjamin Herrenschmidt [EMAIL PROTECTED]: On Mon, 2008-08-18 at 10:45 +0200, Sébastien Chrétien wrote: Hello, I am developping a Linux for my PPC Board. I must write a define_machine structure (marchdep_calls). Where can I find some Information about functions of this structure ? It isn't well documented unfortunately. Best is to look at what others do... and then find your way through. I agree somebody should write dome doco one day ... in the meantime, feel free to ask questions here. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Clock / Timebase / Bus Frequencies Help
We've got an 8347 based board very similar to the AM asp8347. Core clock is 400MHz. Bus clock is 2Hz. According to the data sheet for the 8347, the decrementer clock runs at a quarter of the rate of the bus clock. I have two questions: In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my system clock runs approximately 4 times too fast. Can anyone point me in the direction of an explanation for the div by 16 rather than 4? If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is passed in, then the clock runs more accurately. However, its still not correct. This gives a decrementer frequency of Hz, but if I hard code the value to 6600Hz, the clock runs accurately. Can anyone shed any light on why the value passed in by the boot loader (redboot) seems to be inaccurate. Cheers, Richard. mail2web LIVE Free email based on Microsoft® Exchange technology - http://link.mail2web.com/LIVE ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
On Mon, 2008-08-18 at 13:35 +0200, Sébastien Chrétien wrote: Can somebody explain me the aim of the function setup_arch in the machine_call structure ? Is this MPC7448 anything like an mpc7448hpc2 ? If so maybe you should start by looking at the code for it in: arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c Even if it's not related, that will give you some idea of what the callbacks are for. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
On Thursday 14 August 2008, Anton Vorontsov wrote: On Thu, Aug 14, 2008 at 04:45:52PM +0200, Laurent Pinchart wrote: On Thursday 14 August 2008, Anton Vorontsov wrote: On Thu, Aug 14, 2008 at 04:04:18PM +0200, Laurent Pinchart wrote: On Friday 08 August 2008, Anton Vorontsov wrote: We'll need this function to write platform-specific hooks to deal with pin's dedicated functions. Quite obviously this will work only for the platforms with 1-to-1 GPIO to PIN mapping. This is stopgap solution till we think out and implement a proper api (pinlib?). How do you support reverting the GPIO mode to non-dedicated ? As we always do with the GPIO API: gpio_direction_*() calls. So the proper sequence to configure a pin in dedicated mode is to set the direction first (which will unset the dedicated mode bit) and then set dedicated mode (which will not touch the direction bit) ? Not exactly. But you can do this way, if you need to preserve a direction. What I did is a bit different though. qe_gpio_set_dedicated() actually just restores a mode that firmware had set up, including direction (since direction could be a part of dedicated configuration). That is, upon GPIO controller registration, we save all registers, then driver can set up a pin to a GPIO mode via standard API, and then it can _revert_ a pin to a dedicated function via qe_gpio_set_dedicated() call. Dedicated function is specified by the firmware (or board file), we're just restoring it. The semantic of the set_dedicated() operation needs to be clearly defined then. I can live with this behaviour, but it might not be acceptable for everybody. Your patch requires the firmware to set a pin in dedicated mode at bootup in order to be used later in dedicated mode. If, for some reason (driver not loaded, ...), no GPIO user shows up for that pin, it will stay configured in dedicated mode. It might be better to set the PAR bit unconditionally in qe_gpio_set_dedicated() instead of restoring its value. That way the board initialization code could just set the DIR, DAT and ODR bits for dedicated mode but still configure the pin in GPIO mode. -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
The mpc7448hpc2 uses a tsi108-bridge. My board uses an IP on a FPGA.. I read the code of mpc7448_hpc2.c. It uses a ioremap in order to iniatilize the tsi108 registers. But I have already initialized MMU with my registers in HEAD_32.S. Do I need to use ioremap in setup_arch() ? 2008/8/18, Michael Ellerman [EMAIL PROTECTED]: On Mon, 2008-08-18 at 13:35 +0200, Sébastien Chrétien wrote: Can somebody explain me the aim of the function setup_arch in the machine_call structure ? Is this MPC7448 anything like an mpc7448hpc2 ? If so maybe you should start by looking at the code for it in: arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c Even if it's not related, that will give you some idea of what the callbacks are for. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
On Mon, Aug 18, 2008 at 03:58:46PM +0200, Laurent Pinchart wrote: [...] Not exactly. But you can do this way, if you need to preserve a direction. What I did is a bit different though. qe_gpio_set_dedicated() actually just restores a mode that firmware had set up, including direction (since direction could be a part of dedicated configuration). That is, upon GPIO controller registration, we save all registers, then driver can set up a pin to a GPIO mode via standard API, and then it can _revert_ a pin to a dedicated function via qe_gpio_set_dedicated() call. Dedicated function is specified by the firmware (or board file), we're just restoring it. The semantic of the set_dedicated() operation needs to be clearly defined then. It is. We set up a dedicated function that firmware (or board file) has configured. I can live with this behaviour, but it might not be acceptable for everybody. For example? Your patch requires the firmware to set a pin in dedicated mode at bootup in order to be used later in dedicated mode. Yes. On a PowerPC this is always true: firmware should set up PIO config. Linux' board file could fixup the firmware though. Another option would be to add some argument to the set_dedicated call, thus the software could specify arbitrary dedicated function (thus no need to save/restore anything). But this would be SOC-model specific, thus no driver can use this argument anyway. If, for some reason (driver not loaded, ...), no GPIO user shows up for that pin, it will stay configured in dedicated mode. Yes. It might be better to set the PAR bit unconditionally in Why it might be better? That way you may set up wrong _GPIO_ mode, because you didn't set PAR bit (when PAR bit set DIR/ODR/DAT bits are losing their meanings). qe_gpio_set_dedicated() instead of restoring its value. That way the board initialization code could just set the DIR, DAT and ODR bits for dedicated mode but still configure the pin in GPIO mode. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [fs_enet] powerpc: Fix SCC Ethernet on CPM2, and crash in fs_enet_rx_napi()
On Jun 11, 2008, at 7:32 PM, Vitaly Bordug wrote: From: Heiko Schocher [EMAIL PROTECTED] Initially posted on: http://ozlabs.org/pipermail/linuxppc-dev/2008-January/049682.html Feedback is addressed in this version (yes, this patch was floating around for a while...) Signed-off-by: Heiko Schocher [EMAIL PROTECTED] Signed-off-by: Vitaly Bordug [EMAIL PROTECTED] --- drivers/net/fs_enet/fs_enet-main.c | 10 +- drivers/net/fs_enet/mac-scc.c |8 +++- include/asm-powerpc/cpm2.h |5 + 3 files changed, 21 insertions(+), 2 deletions(-) Jeff, any reason this wasn't picked up ? - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3 v2] powerpc: make CMO paging space pool ID and page size available
During platform setup, save off the primary/secondary paging space pool IDs
and the page size. Added accessors in hvcall.h for these variables.
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
I wrote Submitted-by on the last patch for some strange reason, that't
the only thing changed here.
---
arch/powerpc/include/asm/hvcall.h | 21 +
arch/powerpc/platforms/pseries/setup.c | 28
2 files changed, 41 insertions(+), 8 deletions(-)
Index: b/arch/powerpc/include/asm/hvcall.h
===
--- a/arch/powerpc/include/asm/hvcall.h
+++ b/arch/powerpc/include/asm/hvcall.h
@@ -292,6 +292,27 @@ struct hvcall_mpp_data {
int h_get_mpp(struct hvcall_mpp_data *);
+#ifdef CONFIG_PPC_PSERIES
+extern int CMO_PrPSP;
+extern int CMO_SecPSP;
+extern unsigned long CMO_PageSize;
+
+static inline int cmo_get_primary_psp(void)
+{
+ return CMO_PrPSP;
+}
+
+static inline int cmo_get_secondary_psp(void)
+{
+ return CMO_SecPSP;
+}
+
+static inline unsigned long cmo_get_page_size(void)
+{
+ return CMO_PageSize;
+}
+#endif /* CONFIG_PPC_PSERIES */
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
Index: b/arch/powerpc/platforms/pseries/setup.c
===
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -68,6 +68,9 @@
#include plpar_wrappers.h
#include pseries.h
+int CMO_PrPSP = -1;
+int CMO_SecPSP = -1;
+unsigned long CMO_PageSize = (ASM_CONST(1) IOMMU_PAGE_SHIFT);
int fwnmi_active; /* TRUE if an FWNMI handler is present */
@@ -325,8 +328,7 @@ void pSeries_cmo_feature_init(void)
{
char *ptr, *key, *value, *end;
int call_status;
- int PrPSP = -1;
- int SecPSP = -1;
+ int page_order = IOMMU_PAGE_SHIFT;
pr_debug( - fw_cmo_feature_init()\n);
spin_lock(rtas_data_buf_lock);
@@ -365,21 +367,31 @@ void pSeries_cmo_feature_init(void)
break;
}
- if (0 == strcmp(key, PrPSP))
- PrPSP = simple_strtol(value, NULL, 10);
+ if (0 == strcmp(key, CMOPageSize))
+ page_order = simple_strtol(value, NULL, 10);
+ else if (0 == strcmp(key, PrPSP))
+ CMO_PrPSP = simple_strtol(value, NULL, 10);
else if (0 == strcmp(key, SecPSP))
- SecPSP = simple_strtol(value, NULL, 10);
+ CMO_SecPSP = simple_strtol(value, NULL, 10);
value = key = ptr + 1;
}
ptr++;
}
- if (PrPSP != -1 || SecPSP != -1) {
+ /* Page size is returned as the power of 2 of the page size,
+* convert to the page size in bytes before returning
+*/
+ CMO_PageSize = 1 page_order;
+ pr_debug(CMO_PageSize = %lu\n, CMO_PageSize);
+
+ if (CMO_PrPSP != -1 || CMO_SecPSP != -1) {
pr_info(CMO enabled\n);
- pr_debug(CMO enabled, PrPSP=%d, SecPSP=%d\n, PrPSP, SecPSP);
+ pr_debug(CMO enabled, PrPSP=%d, SecPSP=%d\n, CMO_PrPSP,
+CMO_SecPSP);
powerpc_firmware_features |= FW_FEATURE_CMO;
} else
- pr_debug(CMO not enabled, PrPSP=%d, SecPSP=%d\n, PrPSP,
SecPSP);
+ pr_debug(CMO not enabled, PrPSP=%d, SecPSP=%d\n, CMO_PrPSP,
+CMO_SecPSP);
spin_unlock(rtas_data_buf_lock);
pr_debug( - fw_cmo_feature_init()\n);
}
- End forwarded message -
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
On Monday 18 August 2008, Anton Vorontsov wrote: On Mon, Aug 18, 2008 at 03:58:46PM +0200, Laurent Pinchart wrote: [...] Not exactly. But you can do this way, if you need to preserve a direction. What I did is a bit different though. qe_gpio_set_dedicated() actually just restores a mode that firmware had set up, including direction (since direction could be a part of dedicated configuration). That is, upon GPIO controller registration, we save all registers, then driver can set up a pin to a GPIO mode via standard API, and then it can _revert_ a pin to a dedicated function via qe_gpio_set_dedicated() call. Dedicated function is specified by the firmware (or board file), we're just restoring it. The semantic of the set_dedicated() operation needs to be clearly defined then. It is. We set up a dedicated function that firmware (or board file) has configured. A comment in the source would help. I can live with this behaviour, but it might not be acceptable for everybody. For example? Your patch requires the firmware to set a pin in dedicated mode at bootup in order to be used later in dedicated mode. Yes. On a PowerPC this is always true: firmware should set up PIO config. Linux' board file could fixup the firmware though. That's not what I meant. What if the hardware requires to pin to be configured in GPIO mode with a fixed value until the SOC-specific driver that will drive the GPIO is loaded ? That's not possible with your API. Until a SOC peripheral is initialized by its associated Linux driver, the behaviour of a GPIO pin in dedicated mode will be undefined. The firmware/board code will probably want to set the pin as a GPIO output with a fixed value until the driver initializes the hardware. Another option would be to add some argument to the set_dedicated call, thus the software could specify arbitrary dedicated function (thus no need to save/restore anything). But this would be SOC-model specific, thus no driver can use this argument anyway. Drivers that require dedicated mode are SOC-specific anyway. If, for some reason (driver not loaded, ...), no GPIO user shows up for that pin, it will stay configured in dedicated mode. Yes. It might be better to set the PAR bit unconditionally in Why it might be better? Because, as explained a few lines down, the board initialization code will be able to configure a pin in a known state (PAR not set) at boot time until a driver requests the pin to be switched to dedicated mode. That way you may set up wrong _GPIO_ mode, because you didn't set PAR bit (when PAR bit set DIR/ODR/DAT bits are losing their meanings). qe_gpio_set_dedicated() instead of restoring its value. That way the board initialization code could just set the DIR, DAT and ODR bits for dedicated mode but still configure the pin in GPIO mode. -- Laurent Pinchart CSE Semaphore Belgium Chaussee de Bruxelles, 732A B-1410 Waterloo Belgium T +32 (2) 387 42 59 F +32 (2) 387 42 75 signature.asc Description: This is a digitally signed message part. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Eran Liberty wrote: After compiling a kernel with ftrace I started to experience all sorts of crashes. Just to make sure... ftrace enables markers too, and RCU has tracing with the markers. This may not be the problem, but I just want to eliminate as many variables as possible. Could you disable ftrace, but keep the markers on too. Also, could you enable ftrace again and turn on the FTRACE_STARTUP_TEST. Thanks, -- Steve I have a powerpc env which closly resemble mpc8548cds_defconfig. I have produced the crash in seconds by issuing: while [ 1 ] ; do find / /dev/null ; echo . ; done Liberty here are some of the kernel crashes: --- ~ # find /proc/ -name kft find: /proc/150/net/softnet_stat: No such file or direOops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: NIP: c00bd6fc LR: c00bd6fc CTR: REGS: ddfc3d50 TRAP: 0700 Not tainted (2.6.27-rc2) MSR: 00029000 EE,ME CR: 20002284 XER: 2000 TASK = ddcccde0[1699] 'find' THREAD: ddfc2000 GPR00: ddfc3e00 ddcccde0 dd895580 ddfc3e30 c00b5da0 ddfc3e90 0003 GPR08: c00ece54 0370 00145505 0003 80002282 100ad874 10083ca0 10083cd8 GPR16: 10083cd0 0008 c00b5da0 ddfc3f18 c00ece54 df465720 GPR24: d7431900 ddfc3e30 dd895580 c038 dd895580 ddfc3e30 ddfc3e00 NIP [c00bd6fc] d_lookup+0x40/0x90 LR [c00bd6fc] d_lookup+0x40/0x90 Call Trace: [ddfc3e00] [c006ade4] rcu_process_callbacks+0x48/0x60 (unreliable) [ddfc3e20] [c00eb514] proc_fill_cache+0x94/0x1b0 [ddfc3e80] [c00ef720] proc_task_readdir+0x294/0x3c4 [ddfc3ee0] [c00b60fc] vfs_readdir+0xb8/0xd8 [ddfc3f10] [c00b619c] sys_getdents64+0x80/0x104 [ddfc3f40] [c0010554] ret_from_syscall+0x0/0x3c Instruction dump: 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0 73c1 7f83e378 7fa4eb78 4082002f 2f83 409e0030 801b52a0 ctory ---[ end trace 6b059a7f5ba5a55a ]--- --- Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: gplonly_api NIP: c00bd6fc LR: c00bd6fc CTR: REGS: df52dc40 TRAP: 0700 Not tainted (2.6.27-rc2) MSR: 00029000 EE,ME CR: 20082422 XER: 2000 TASK = ddc2e060[2294] 'eeprom' THREAD: df52c000 GPR00: df52dcf0 ddc2e060 dd82c700 df52dd58 df52dd48 dd82c75e GPR08: c080 000311f0 df52dd10 20002488 1001e75c 100b 1008e90c GPR16: bfd15a50 df52de6c df52dd58 fff4 c038 df52dd50 df52dd48 dd9303fc GPR24: dc3a6800 dd930390 df52dd58 c038 dd82c700 df52dd58 0006 df52dcf0 NIP [c00bd6fc] d_lookup+0x40/0x90 LR [c00bd6fc] d_lookup+0x40/0x90 Call Trace: [df52dcf0] [df52dd48] 0xdf52dd48 (unreliable) [df52dd10] [c00b07a0] do_lookup+0xe8/0x220 [df52dd40] [c00b222c] __link_path_walk+0x174/0xd54 [df52ddb0] [c00b2e64] path_walk+0x58/0xe0 [df52dde0] [c00b2fd4] do_path_lookup+0x78/0x13c [df52de10] [c00b3f3c] __path_lookup_intent_open+0x68/0xdc [df52de40] [c00b3fd8] path_lookup_open+0x28/0x40 [df52de50] [c00b4234] do_filp_open+0xa0/0x798 [df52df00] [c00a3b80] do_sys_open+0x70/0x114 [df52df30] [c00a3c98] sys_open+0x38/0x50 [df52df40] [c0010554] ret_from_syscall+0x0/0x3c Instruction dump: 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0 73c1 7f83e378 7fa4eb78 4082002f 2f83 409e0030 801b52a0 om_version(Canno---[ end trace 0cef3c8cb49d09de ]--- --- Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: bridge stp llc tun beacon_freescale(P) 80211(P) shm_freescale(P) ath_remote_regs_freescale(P) exsw load_local_fpga_freescale 8021q poe_fi NIP: c00bd6fc LR: c00bd6fc CTR: REGS: dd555c50 TRAP: 0700 Tainted: P (2.6.27-rc2) MSR: 00029000 EE,ME CR: 24082282 XER: 2000 TASK = df4669a0[4976] 'find' THREAD: dd554000 GPR00: dd555d00 df4669a0 dd82ae00 dd555d68 dd555d58 dd82ae5b 100234ec GPR08: c080 0002dd0c dd555d20 24000288 100ad874 100936f8 1008a1d0 GPR16: 10083f80 dd555e2c dd555d68 fff4 c038 dd555d60 dd555d58 dd9565d4 GPR24: dc3db480 dd956568 dd555d68 c038 dd82ae00 dd555d68 dd555d00 NIP [c00bd6fc] d_lookup+0x40/0x90 LR [c00bd6fc] d_lookup+0x40/0x90 Call Trace: [dd555d00] [dd555d58] 0xdd555d58 (unreliable) [dd555d20] [c00b07a0] do_lookup+0xe8/0x220 [dd555d50] [c00b265c] __link_path_walk+0x5a4/0xd54 [dd555dc0] [c00b2e64] path_walk+0x58/0xe0 [dd555df0] [c00b2fd4] do_path_lookup+0x78/0x13c [dd555e20] [c00b3cd0] user_path_at+0x64/0xac [dd555e90] [c00aac04] vfs_lstat_fd+0x34/0x74 [dd555ec0] [c00aacd8] vfs_lstat+0x30/0x48 [dd555ed0] [c00aad20] sys_lstat64+0x30/0x5c [dd555f40] [c0010554] ret_from_syscall+0x0/0x3c Instruction dump: 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db52a0 73c1 7f83e378 7fa4eb78 4082002f 2f83 409e0030 801b52a0 76/auxv /proc/4---[ end trace 0deef0827ce9df4b ]--- --- Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: bridge stp llc tun beacon_freescale(P) 80211(P) shm_freescale(P) ath_remote_regs_freescale(P) exsw
Re: [PATCH] powerpc: 85xx: TQM8548: DTS file fixes and cleanup
On Aug 17, 2008, at 3:51 AM, Wolfgang Grandegger wrote: Due to the missing compatible property for the SOC, the MPC I2C buses are not found any more. This patch fixes this issue. Furthermore it corrects the name of the SOC node and adds the missing I2C node for the RTC. Signed-off-by: Wolfgang Grandegger [EMAIL PROTECTED] --- arch/powerpc/boot/dts/tqm8548-bigflash.dts |8 +++- arch/powerpc/boot/dts/tqm8548.dts |3 ++- 2 files changed, 9 insertions(+), 2 deletions(-) applied. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] gpiolib: make gpio_to_chip() public
On Mon, Aug 18, 2008 at 04:44:36PM +0200, Laurent Pinchart wrote: On Monday 18 August 2008, Anton Vorontsov wrote: On Mon, Aug 18, 2008 at 03:58:46PM +0200, Laurent Pinchart wrote: [...] Not exactly. But you can do this way, if you need to preserve a direction. What I did is a bit different though. qe_gpio_set_dedicated() actually just restores a mode that firmware had set up, including direction (since direction could be a part of dedicated configuration). That is, upon GPIO controller registration, we save all registers, then driver can set up a pin to a GPIO mode via standard API, and then it can _revert_ a pin to a dedicated function via qe_gpio_set_dedicated() call. Dedicated function is specified by the firmware (or board file), we're just restoring it. The semantic of the set_dedicated() operation needs to be clearly defined then. It is. We set up a dedicated function that firmware (or board file) has configured. A comment in the source would help. I can live with this behaviour, but it might not be acceptable for everybody. For example? Your patch requires the firmware to set a pin in dedicated mode at bootup in order to be used later in dedicated mode. Yes. On a PowerPC this is always true: firmware should set up PIO config. Linux' board file could fixup the firmware though. That's not what I meant. What if the hardware requires to pin to be configured in GPIO mode with a fixed value until the SOC-specific driver that will drive the GPIO is loaded ? That's not possible with your API. Yes, this isn't possible with this API. Because you can do this with standard GPIO API! ;-) Just call gpio_direction_*() in the board file, before probing the hardware. Until a SOC peripheral is initialized by its associated Linux driver, the behaviour of a GPIO pin in dedicated mode will be undefined. Huh?! Then all current software is simply broken: we're setting pinmux config _prior_ to controller initialization. The firmware/board code will probably want to set the pin as a GPIO output with a fixed value until the driver initializes the hardware. Probably? Do you have any such hardware? Another option would be to add some argument to the set_dedicated call, thus the software could specify arbitrary dedicated function (thus no need to save/restore anything). But this would be SOC-model specific, thus no driver can use this argument anyway. Drivers that require dedicated mode are SOC-specific anyway. I didn't say SOC-specific. I said SOC-model specific, which means that the driver would be not portable even across QE chips (i.e. MPC8323 vs. MPC8360, you can assume that the CLK12 function is having same PAR/ODR/DAT/DIR bits). If, for some reason (driver not loaded, ...), no GPIO user shows up for that pin, it will stay configured in dedicated mode. Yes. It might be better to set the PAR bit unconditionally in Why it might be better? Because, as explained a few lines down, the board initialization code will be able to configure a pin in a known state (PAR not set) at boot time until a driver requests the pin to be switched to dedicated mode. You can do this as I described above. But prior to this, yes, you have to configure the pins and let Linux save these values. There is no other way to pass this information, unfortunately. -- Anton Vorontsov email: [EMAIL PROTECTED] irc://irc.freenode.net/bd2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc: Improve message for vio bus entitlement panic
Add information regarding the available and required entitlement amounts
to the message displayed for the panic when insufficient entitlement is
provided at boot.
Signed-off-by: Robert Jennings [EMAIL PROTECTED]
---
I had typed Submitted-by instead of Signed-off-by previously.
---
arch/powerpc/kernel/vio.c |4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
Index: b/arch/powerpc/kernel/vio.c
===
--- a/arch/powerpc/kernel/vio.c
+++ b/arch/powerpc/kernel/vio.c
@@ -899,7 +899,9 @@ static void vio_cmo_bus_init(void)
if (vio_cmo.reserve.size vio_cmo.entitled) {
printk(KERN_ERR %s: insufficient system entitlement\n,
__func__);
- panic(%s: Insufficient system entitlement, __func__);
+ panic(%s: Insufficient system entitlement. Available: %lu
+ Required: %lu, __func__, vio_cmo.entitled,
+ vio_cmo.reserve.size);
}
/* Set the remaining accounting variables */
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Clock / Timebase / Bus Frequencies Help
On Mon, Aug 18, 2008 at 07:52:12AM -0400, [EMAIL PROTECTED] wrote: We've got an 8347 based board very similar to the AM asp8347. Core clock is 400MHz. Bus clock is 2Hz. According to the data sheet for the 8347, the decrementer clock runs at a quarter of the rate of the bus clock. I have two questions: In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my system clock runs approximately 4 times too fast. Can anyone point me in the direction of an explanation for the div by 16 rather than 4? It's a bug, which I pointed out here: http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is passed in, then the clock runs more accurately. However, its still not correct. This gives a decrementer frequency of Hz, but if I hard code the value to 6600Hz, the clock runs accurately. Can anyone shed any light on why the value passed in by the boot loader (redboot) seems to be inaccurate. Redboot probably has the wrong crystal frequency hardcoded. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc, scc: duplicate SCC_UHC_USBCEN
untested, is it correct?
---
arch/powerpc/platforms/cell/celleb_scc.h:224:
#define SCC_UHC_USBEN 0x0001
#define SCC_UHC_USBCEN 0x0002
---
diff --git a/arch/powerpc/platforms/cell/celleb_scc_uhc.c
b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
index d63b720..b086f33 100644
--- a/arch/powerpc/platforms/cell/celleb_scc_uhc.c
+++ b/arch/powerpc/platforms/cell/celleb_scc_uhc.c
@@ -31,7 +31,7 @@
static inline int uhc_clkctrl_ready(u32 val)
{
- const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBCEN;
+ const u32 mask = SCC_UHC_USBCEN | SCC_UHC_USBEN;
return((val mask) == mask);
}
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Mathieu Desnoyers wrote:
Steve ? I just noticed this :
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
unsigned char *new_code)
{
unsigned replaced;
unsigned old = *(unsigned *)old_code;
unsigned new = *(unsigned *)new_code;
int faulted = 0;
/*
* Note: Due to modules and __init, code can
* disappear and change, we need to protect against faulting
* as well as code changing.
*
* No real locking needed, this code is run through
* kstop_machine.
*/
asm volatile (
1: lwz %1, 0(%2)\n
cmpw%1, %5\n
bne 2f\n
stwu%3, 0(%2)\n
2:\n
.section .fixup, \ax\\n
3: li %0, 1\n
b 2b\n
.previous\n
.section __ex_table,\a\\n
_ASM_ALIGN \n
_ASM_PTR 1b, 3b\n
.previous
: =r(faulted), =r(replaced)
: r(ip), r(new),
0(faulted), r(old)
: memory);
if (replaced != old replaced != new)
faulted = 2;
if (!faulted)
flush_icache_range(ip, ip + 8);
return faulted;
}
What happens if you are really unlucky and get the following execution
sequence ?
Load module A at address 0xddfc3e00
Populate ftrace function table while the system runs
Unload module A
Load module B at address 0xddfc3e00
Activate ftrace
- At that point, since there is another module loaded in the same
address space, it won't fault. If there happens to be an instruction
which looks exactly like the instruction we are replacing at the same
location, we are introducing a bug. True both on x86 ans powerpc...
Hi Mathieu,
Yep I know of this issue, and it is very unlikely it would happen. But
that's not good enough, so this is why I did this:
http://marc.info/?l=linux-kernelm=121876928124384w=2
http://marc.info/?l=linux-kernelm=121876938524523w=2
;-)
On powerpc it would be less likely an issue since the code segments are
all 4 bytes aligned. And a call being replaced would be a call to mcount
(relative jump). A call to mcount would be the same for both. Then
again, we could be replacing a nop, but most likely that wouldn't hurt
either, since nops are seldom used, and if we did call mcount, it would
probably not hurt. But it would be an issue if Module B happen to put a
data section that matched the code to jmp to mcount or a nop.
-- Steve
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Hi Paul, I can't boot zImage with your patches. I'm getting the following error message from prom_init.c Error: You can't boot a kdump kernel from OF! This is due to the check: if (PHYSICAL_START 0) prom_panic(Error: You can't boot a kdump kernel from OF!\n); where PHYSICAL_START is kernstart_addr, and this variable needs to be referred through RELOC macro But even after commenting the above check, I am not able to boot zImage. snip boot message Building dt structure... Device tree strings 0x02ce4000 - 0×02ce5034 Device tree struct 0×02ce6000 - 0×02cf Calling quiesce … returning from prom_init snip and the system hangs It has CONFIG_RELOCATABLE set, (CONFIG_CRASH_DUMP is not set). I even tried booting zImage through netboot, it also fails at the same place. If you need, I can give the .config I use. Regards, Mohan. Paul Mackerras wrote: The following series of patches implement support for a relocatable kernel by building it as a position-independent executable (PIE). When the linker is given the -pie flag, it creates an executable that contains dynamic relocations which can be used to relocate the image at boot time for any desired base address. This patch series adds a CONFIG_RELOCATABLE config option for 64-bit which links the kernel with -pie and arranges to process the relocations in early boot. With the first 4 patches applied, a relocatable kernel will still copy itself down to real address 0. The last patch changes things so that a relocatable kernel will run wherever it was loaded. This last patch is pretty much just a proof of concept since it doesn't do anything to ensure appropriate alignment of the base address (the base address needs to be 16kB aligned). We probably want to work out whether we are a kdump kernel and run in-place if so, or copy down to 0 if not. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Mathieu Desnoyers wrote: asm volatile ( 1: lwz %1, 0(%2)\n cmpw%1, %5\n bne 2f\n stwu%3, 0(%2)\n 2:\n .section .fixup, \ax\\n 3: li %0, 1\n b 2b\n .previous\n .section __ex_table,\a\\n _ASM_ALIGN \n _ASM_PTR 1b, 3b\n .previous : =r(faulted), =r(replaced) : r(ip), r(new), 0(faulted), r(old) : memory); Some (most likely unrelated) nits in the above inline asm: Should use a b constraint for %2, or you could get r0. Or, use an m constraint with %U2%X2 after the lwz/stw. Why stwu with an offset of zero, BTW? %1 also needs to be an early clobber. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 18 Aug 2008, Scott Wood wrote: Mathieu Desnoyers wrote: asm volatile ( 1: lwz %1, 0(%2)\n cmpw%1, %5\n bne 2f\n stwu%3, 0(%2)\n 2:\n .section .fixup, \ax\\n 3: li %0, 1\n b 2b\n .previous\n .section __ex_table,\a\\n _ASM_ALIGN \n _ASM_PTR 1b, 3b\n .previous : =r(faulted), =r(replaced) : r(ip), r(new), 0(faulted), r(old) : memory); Some (most likely unrelated) nits in the above inline asm: Thanks, Should use a b constraint for %2, or you could get r0. I will make an updated patch. Or, use an m constraint with %U2%X2 after the lwz/stw. The 'b' seems easier ;-) Why stwu with an offset of zero, BTW? Because it worked :-) Really, it has been a while since I did any PPC assembly, and I didn't break out the old reference manuals to do this. I simply looked at other asm code, and followed suit. I compiled and tested it, and it worked. I did make a disclaimer about my rusty PPC knowledge when I posted the code. %1 also needs to be an early clobber. Not exactly sure what you mean by the above. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Steven Rostedt wrote: Should use a b constraint for %2, or you could get r0. I will make an updated patch. Or, use an m constraint with %U2%X2 after the lwz/stw. The 'b' seems easier ;-) The advantage of the latter is that it allows GCC to choose indexed or update instructions -- but that's merely an optimization. Switching to b is enough to avoid the potential bug. %1 also needs to be an early clobber. Not exactly sure what you mean by the above. %1 is written to before some inputs are consumed, so you need to use =r rather than =r so that GCC won't use the same register for both. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
* Eran Liberty ([EMAIL PROTECTED]) wrote: Steven Rostedt wrote: Eran Liberty wrote: After compiling a kernel with ftrace I started to experience all sorts of crashes. Just to make sure... ftrace enables markers too, and RCU has tracing with the markers. This may not be the problem, but I just want to eliminate as many variables as possible. Could you disable ftrace, but keep the markers on too. Also, could you enable ftrace again and turn on the FTRACE_STARTUP_TEST. for the fun of it I took out all my propriety modules; so now its a non tainted kernel. Here is the matrix: !FTRACE x !MARKERS = stable !FTRACE x MARKERS = stable FTRACE x !MARKERS = n/a (FTRACE forces MARKERS) FTRACE x MARKERS = unstable FTRACE x FTRACE_STARTUP_TEST x MARKERS = unstable + tests passed Testing tracer sched_switch: PASSED Testing tracer ftrace: PASSED Testing dynamic ftrace: PASSED Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: NIP: c00bbb20 LR: c00bbb20 CTR: REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2) MSR: 00029000 EE,ME CR: 24082282 XER: 2000 TASK = ddcce060[1707] 'find' THREAD: dd5b GPR00: dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b 100234ec GPR08: c080 00019330 dd5b1d20 24000288 100ad874 100936f8 1008a1d0 GPR16: 10083f80 dd5b1e2c dd5b1d68 fff4 c038 dd5b1d60 dd5b1d58 dd802084 GPR24: dc3d7700 dd802018 dd5b1d68 c038 dd801180 dd5b1d68 dd5b1d00 NIP [c00bbb20] d_lookup+0x40/0x90 LR [c00bbb20] d_lookup+0x40/0x90 Call Trace: [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable) Can you check if, at some point during the system execution (starting from boot), 0xdd5b1d58 is an address where a module is loaded ? (the module can be later unloaded, what I wonder is if this address would appear to have had a loaded+unloaded module). Actually, could you try to compile your kernel without MODULE_UNLOAD ? Mathieu [dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220 [dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54 [dd5b1dc0] [c00b1288] path_walk+0x58/0xe0 [dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c [dd5b1e20] [c00b20f4] user_path_at+0x64/0xac [dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74 [dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48 [dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c [dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c Instruction dump: 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0 73c1 7f83e378 7fa4eb78 4082002f 2f83 409e0030 801b32a0 ---[ end trace 1eb8fd7adac2bb65 ]--- Liberty -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 18 Aug 2008, Scott Wood wrote: Mathieu Desnoyers wrote: asm volatile ( 1: lwz %1, 0(%2)\n cmpw%1, %5\n bne 2f\n stwu%3, 0(%2)\n 2:\n .section .fixup, \ax\\n 3: li %0, 1\n b 2b\n .previous\n .section __ex_table,\a\\n _ASM_ALIGN \n _ASM_PTR 1b, 3b\n .previous : =r(faulted), =r(replaced) : r(ip), r(new), 0(faulted), r(old) : memory); Some (most likely unrelated) nits in the above inline asm: Should use a b constraint for %2, or you could get r0. Or, use an m constraint with %U2%X2 after the lwz/stw. What syntax to do that with? lwz %1,0(%U2) stu %3, 0(%X2) I'm new to those. (and the above does not compile) Why stwu with an offset of zero, How else to do it? stwu %3, (%2) does not compile for me. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 18 Aug 2008, Eran Liberty wrote: Steven Rostedt wrote: Eran Liberty wrote: After compiling a kernel with ftrace I started to experience all sorts of crashes. Just to make sure... ftrace enables markers too, and RCU has tracing with the markers. This may not be the problem, but I just want to eliminate as many variables as possible. Could you disable ftrace, but keep the markers on too. Also, could you enable ftrace again and turn on the FTRACE_STARTUP_TEST. for the fun of it I took out all my propriety modules; so now its a non tainted kernel. Here is the matrix: !FTRACE x !MARKERS = stable !FTRACE x MARKERS = stable FTRACE x !MARKERS = n/a (FTRACE forces MARKERS) FTRACE x MARKERS = unstable FTRACE x FTRACE_STARTUP_TEST x MARKERS = unstable + tests passed Thanks Testing tracer sched_switch: PASSED Testing tracer ftrace: PASSED Testing dynamic ftrace: PASSED Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: NIP: c00bbb20 LR: c00bbb20 CTR: Could you load this into gdb for me and show me the output of: gdb li *0xc00bbb20 (Assuming you compiled with debuginfo on) and... gdb disass 0xc00bbb20 REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2) MSR: 00029000 EE,ME CR: 24082282 XER: 2000 TASK = ddcce060[1707] 'find' THREAD: dd5b GPR00: dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b 100234ec GPR08: c080 00019330 dd5b1d20 24000288 100ad874 100936f8 1008a1d0 GPR16: 10083f80 dd5b1e2c dd5b1d68 fff4 c038 dd5b1d60 dd5b1d58 dd802084 GPR24: dc3d7700 dd802018 dd5b1d68 c038 dd801180 dd5b1d68 dd5b1d00 NIP [c00bbb20] d_lookup+0x40/0x90 LR [c00bbb20] d_lookup+0x40/0x90 Call Trace: [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable) [dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220 [dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54 [dd5b1dc0] [c00b1288] path_walk+0x58/0xe0 [dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c [dd5b1e20] [c00b20f4] user_path_at+0x64/0xac [dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74 [dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48 [dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c [dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c Instruction dump: 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0 73c1 7f83e378 7fa4eb78 4082002f 2f83 409e0030 801b32a0 Ouch! we have a instruction. I'm almost done with the new mcount record for PPC (I have it done for ppc64, I'm just porting it to 32). I'm thinking this new code may solve your issues too. I hate the daemon. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Steven Rostedt wrote: What syntax to do that with? lwz %1,0(%U2) stu %3, 0(%X2) I'm new to those. (and the above does not compile) lwz%U2%X2 %1, %2 stw%U2%X2 %3, %2 Why stwu with an offset of zero, How else to do it? stwu %3, (%2) does not compile for me. stw %3, 0(%2) The u tells it to write the effective address back to %2 -- but with an offset of zero, the effective address is unchanged. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 18 Aug 2008, Scott Wood wrote: Steven Rostedt wrote: What syntax to do that with? lwz %1,0(%U2) stu %3, 0(%X2) I'm new to those. (and the above does not compile) lwz%U2%X2 %1, %2 stw%U2%X2 %3, %2 Thanks, that's new to me. Why stwu with an offset of zero, How else to do it? stwu %3, (%2) does not compile for me. stw %3, 0(%2) The u tells it to write the effective address back to %2 -- but with an offset of zero, the effective address is unchanged. Ah! Right! /me should open up his PowerPC ref books again :-p -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
The mmu is still disabled at this point. What is marked as readonly is the text section of the vmlinux file generated when compiling the kernel. And since the code tries to write to the text section, I assumed it was the reason for the segmentation fault. I'm not sure how this is dealt with on real hardware. Can somebody please explain how is it supposed to work ? Is it ok to write to text section that you load on real hardware as readonly ? (again, no mmu involved, as it is still turned off, so i'm not sure who's guarding this section against writing) On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] you wrote: Hello, First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in latest versions, but i assume the code is still the same and just moved to powerpc. There is a piece of code in the early initialization of the 2.6 kernel that identifies the cpu type and then tries to eliminate code that does not apply to the current cpu. This is done by writing nop's over sections of code that are not needed (do_cpu_ftr_fixups in arch/ppc/kernel/misc.S) When I try to run the kernel in a ppc emulator, I get a segmentation fault in do_cpu_ftr_fixups. From examining the section headers of the vmlinux, the text section is marked as readonly. The piece of code above mentioned is trying to write a nop to memory location inside the text section which is readonly, so that explains the sigsegv error. Any segv in the emulator sounds like a bug in the emulator. If the page really is marked read only, then writing to it should cause a page fault. Since the kernel does run on boards with ppc cpu's, can somebody explain how come this is actually working ? Or if/where I am mistaking with my assumptions ? Thank you P.S. please add me in cc in a reply to this message ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Clock / Timebase / Bus Frequencies Help
Hi, I have a similar problem with custom MPC8360 board. I am able to boot Linux with the mpc836x_dts.dtb provided by freescale. but when use dtb customised for my board i am unable to boot Linux. It is hanging after the console handover to real console from boot console. I am filling all the frequencies properly, can someone help me to fix this Where to set the baud rate in dts file. Here is the log: = tftp $loadaddr /nfk684/vpm_test/uImage Using FSL UEC0 device TFTP from server 192.168.0.2; our IP address is 192.168.0.100 Filename '/nfk684/vpm_test/uImage'. Load address: 0x20 Loading: # ## done Bytes transferred = 1095689 (10b809 hex) = tftp $fdtaddr /nfk684/vpm_test/mpc8360_vpm.dtb Using FSL UEC0 device TFTP from server 192.168.0.2; our IP address is 192.168.0.100 Filename '/nfk684/vpm_test/mpc8360_vpm.dtb'. Load address: 0x40 Loading: # done Bytes transferred = 12288 (3000 hex) = bootm $loadaddr - $fdtaddr ## Booting image at 0020 ... Image Name: Linux-2.6.22 Image Type: PowerPC Linux Kernel Image (gzip compressed) Data Size:1095625 Bytes = 1 MB Load Address: Entry Point: Verifying Checksum ... OK Uncompressing Kernel Image ... OK Booting using the fdt at 0x40 Probing machine type Using MPC8360 VPM machine description Linux version 2.6.22 ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #17 Fri Aug 15 16:13:41 CDT 2008 setup_arch: bootmem mpc8360_vpm_setup_arch() Bad clock source for time stamp 1 Bad clock source for time stamp 2 arch: exit Zone PFN ranges: DMA 0 -65536 Normal 65536 -65536 early_node_map[1] active PFN ranges 0:0 -65536 Built 1 zonelists. Total pages: 65024 Kernel command line: root=/dev/ram rw console=ttyS1,115200 IPIC (128 IRQ sources) at fdefc700 QEIC (64 IRQ sources) at fdefb080 PID hash table entries: 1024 (order: 10, 4096 bytes) Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 257280k/262144k available (2152k kernel code, 4624k reserved, 96k data, 80k bss, 128k init) Mount-cache hash table entries: 512 NET: Registered protocol family 16 Generic PHY: Registered new driver SCSI subsystem initialized NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 8192 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 8192) TCP reno registered JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler anticipatory registered (default) io scheduler deadline registered io scheduler cfq registered Generic RTC Driver v1.07 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 16) is a 16550A serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 17) is a 16550A console handover: boot [udbg0] - real [ttyS1] Regards Surendra On Mon, Aug 18, 2008 at 07:52:12AM -0400, [EMAIL PROTECTED] wrote: We've got an 8347 based board very similar to the AM asp8347. Core clock is 400MHz. Bus clock is 2Hz. According to the data sheet for the 8347, the decrementer clock runs at a quarter of the rate of the bus clock. I have two questions: In arch/powerpc/boot/redboot-83xx.c, the timebase clock is passed to dt_fixup_cpu_clocks() as bi_busfreq / 16. If I leave it like this, my system clock runs approximately 4 times too fast. Can anyone point me in the direction of an explanation for the div by 16 rather than 4? It's a bug, which I pointed out here: http://ozlabs.org/pipermail/linuxppc-dev/2008-June/058704.html If I change the call to dt_fixup_cpu_clocks so that bi_busfreq/4 is passed in, then the clock runs more accurately. However, its still not correct. This gives a decrementer frequency of Hz, but if I hard code the value to 6600Hz, the clock runs accurately. Can anyone shed any light on why the value passed in by the boot loader (redboot) seems to be inaccurate. Redboot probably has the wrong crystal frequency hardcoded. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
In message [EMAIL PROTECTED] you wrote: The mmu is still disabled at this point. What is marked as readonly is the text section of the vmlinux file generated when compiling the kernel. And since the code tries to write to the text section, I assumed it was the reason for the segmentation fault. Seriously, a seg fault in your emulator is a bug in the emulator! I'm not sure how this is dealt with on real hardware. The CPU seg faults... :-P Can somebody please explain how is it supposed to work ? Is it ok to write to text section that you load on real hardware as readonly ? (again, no mmu involved, as it is still turned off, so i'm not sure who's guarding this section against writing) I'm not sure how this works for 32 bit CPUs, so I can't speak to the details of it. For the 64bit MMU, if you're in real mode (MMU off), nothing can stop this from being written. The kernel ignores the elf sections permissions and does it's own mapping but this can only be enforced once the MMU is on. Mikey On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] you wrote: Hello, First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in latest versions, but i assume the code is still the same and just moved to powerpc. There is a piece of code in the early initialization of the 2.6 kernel that identifies the cpu type and then tries to eliminate code that does not apply to the current cpu. This is done by writing nop's over sections of code that are not needed (do_cpu_ftr_fixups in arch/ppc/kernel/misc.S) When I try to run the kernel in a ppc emulator, I get a segmentation fault in do_cpu_ftr_fixups. From examining the section headers of the vmlinux, the text section is marked as readonly. The piece of code above mentioned is trying to write a nop to memory location inside the text section which is readonly, so that explains the sigsegv error. Any segv in the emulator sounds like a bug in the emulator. If the page really is marked read only, then writing to it should cause a page fault. Since the kernel does run on boards with ppc cpu's, can somebody explain how come this is actually working ? Or if/where I am mistaking with my assumptions ? Thank you P.S. please add me in cc in a reply to this message ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Corrections please ...
Could I get any needed corrections on this. Especially on the ???
[EMAIL PROTECTED] linux-2.6.26]$ diff -U3
include/linux/completion.{h.orig,h}|more
--- include/linux/completion.h.orig 2008-08-13 00:56:52.0 -0700
+++ include/linux/completion.h 2008-08-18 13:00:23.0 -0700
@@ -10,6 +10,16 @@
#include linux/wait.h
+/**
+ * struct completion - structure used to maintain state for a completion
+ * @done: counting variable used to signal completion
+ * @wait: internal wait queue head; used for locking and synchronization
+ *
+ * This is the structure used to maintain the state for a completion. See
+ * also: complete(), wait_for_completion() (and friends _timeout,
+ * _interruptible, _interruptible_timeout, and _killable),
init_completion(),
+ * and macros DECLARE_COMPLETION() and INIT_COMPLETION().
+ */
struct completion {
unsigned int done;
wait_queue_head_t wait;
@@ -36,6 +46,13 @@
# define DECLARE_COMPLETION_ONSTACK(work) DECLARE_COMPLETION(work)
#endif
+/**
+ * init_completion: - Initialize a dynamically allocated completion
+ * @x: completion structure that is to be initialized
+ *
+ * This inline function will initialize a dynamically created completion
+ * structure.
+ */
static inline void init_completion(struct completion *x)
{
x-done = 0;
--- kernel/sched.c.orig 2008-08-13 02:22:42.0 -0700
+++ kernel/sched.c 2008-08-18 13:31:03.0 -0700
@@ -4363,6 +4363,13 @@
}
EXPORT_SYMBOL_GPL(__wake_up_sync); /* For internal use only */
+/**
+ * complete: - signals a single thread waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up a single thread waiting on this completion. If
multiple
+ * threads are waiting ???
+ */
void complete(struct completion *x)
{
unsigned long flags;
@@ -4374,6 +4381,12 @@
}
EXPORT_SYMBOL(complete);
+/**
+ * complete_all: - signals all threads waiting on this completion
+ * @x: holds the state of this particular completion
+ *
+ * This will wake up all threads waiting on this particular completion
event.
+ */
void complete_all(struct completion *x)
{
unsigned long flags;
@@ -4425,12 +4438,27 @@
return timeout;
}
+/**
+ * wait_for_completion: - waits for completion of a task
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is NOT
+ * interruptible and there is no timeout.
+ */
void __sched wait_for_completion(struct completion *x)
{
wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_UNINTERRUPTIBLE);
}
EXPORT_SYMBOL(wait_for_completion);
+/**
+ * wait_for_completion_timeout: - waits for completion of a task
(w/timeout)
+ * @x: holds the state of this particular completion
+ * @timeout: timeout value in jiffies
+ *
+ * This waits to be signaled for completion of a specific task. It is NOT
+ * interruptible. But there is a timeout in jiffies.
+ */
unsigned long __sched
wait_for_completion_timeout(struct completion *x, unsigned long timeout)
{
@@ -4438,6 +4466,13 @@
}
EXPORT_SYMBOL(wait_for_completion_timeout);
+/**
+ * wait_for_completion_interruptible: - waits for completion of a task
(w/intr)
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * interruptible.
+ */
int __sched wait_for_completion_interruptible(struct completion *x)
{
long t = wait_for_common(x, MAX_SCHEDULE_TIMEOUT,
TASK_INTERRUPTIBLE);
@@ -4447,6 +4482,14 @@
}
EXPORT_SYMBOL(wait_for_completion_interruptible);
+/**
+ * wait_for_completion_interruptible_timeout: - waits for completion
(w/(to,int
r))
+ * @x: holds the state of this particular completion
+ * @timeout: timeout value in jiffies
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * interruptible. And there is a timeout in jiffies.
+ */
unsigned long __sched
wait_for_completion_interruptible_timeout(struct completion *x,
unsigned long timeout)
@@ -4455,6 +4498,13 @@
}
EXPORT_SYMBOL(wait_for_completion_interruptible_timeout);
+/**
+ * wait_for_completion_killable: - waits for completion of a task
(killable)
+ * @x: holds the state of this particular completion
+ *
+ * This waits to be signaled for completion of a specific task. It is
+ * killable (???).
+ */
int __sched wait_for_completion_killable(struct completion *x)
{
long t = wait_for_common(x, MAX_SCHEDULE_TIMEOUT, TASK_KILLABLE);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
On Mon, 2008-08-18 at 13:35 +0200, Sébastien Chrétien wrote: Can somebody explain me the aim of the function setup_arch in the machine_call structure ? This is where most of your arch code gets a chance to initialize before most of the core is. The generic core linux code calls the architecture setup_arch() very early during boot, before most other initializations. The powerpc architecture code performs various early initialisations there, on 32-bit that includes unflattening the device-tree, looking for legacy serial ports, etc... and initializing bootmem. It then calls ppc_md.setup_arch to give the platform a chance to perform other platform specific early initializations before the rest of the kernel starts initializing. This is very early, ie, for memory allocation you can only use bootmem for example. Interrupts haven't been initialized or switched on yet, etc... This is typically the place where your arch code will setup it's SMP ops if any, will discover the fixed PCI host bridges, and initialize low level HW components that need early initialization. Ben. 2008/8/18, Sébastien Chrétien [EMAIL PROTECTED]: Ok I am going to copy some examples. 2008/8/18, Benjamin Herrenschmidt [EMAIL PROTECTED]: On Mon, 2008-08-18 at 10:45 +0200, Sébastien Chrétien wrote: Hello, I am developping a Linux for my PPC Board. I must write a define_machine structure (marchdep_calls). Where can I find some Information about functions of this structure ? It isn't well documented unfortunately. Best is to look at what others do... and then find your way through. I agree somebody should write dome doco one day ... in the meantime, feel free to ask questions here. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] powerpc: fix memory leaks in QE library
Fix two memory leaks in the Freescale QE library: add a missing kfree() in
ucc_fast_init() if the ioremap() fails, and update ucc_fast_free() to call
iounmap() on uf_regs.
Based on a patch from Tony Breeds [EMAIL PROTECTED].
Signed-off-by: Timur Tabi [EMAIL PROTECTED]
---
arch/powerpc/sysdev/qe_lib/ucc_fast.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
index 1aecb07..25fbbfa 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_fast.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_fast.c
@@ -208,6 +208,7 @@ int ucc_fast_init(struct ucc_fast_info * uf_info, struct
ucc_fast_private ** ucc
uccf-uf_regs = ioremap(uf_info-regs, sizeof(struct ucc_fast));
if (uccf-uf_regs == NULL) {
printk(KERN_ERR %s: Cannot map UCC registers\n, __func__);
+ kfree(uccf);
return -ENOMEM;
}
@@ -355,6 +356,9 @@ void ucc_fast_free(struct ucc_fast_private * uccf)
if (uccf-ucc_fast_rx_virtual_fifo_base_offset)
qe_muram_free(uccf-ucc_fast_rx_virtual_fifo_base_offset);
+ if (uccf-uf_regs)
+ iounmap(uccf-uf_regs);
+
kfree(uccf);
}
EXPORT_SYMBOL(ucc_fast_free);
--
1.5.5
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote: In message [EMAIL PROTECTED] you wrote: The mmu is still disabled at this point. What is marked as readonly is the text section of the vmlinux file generated when compiling the kernel. And since the code tries to write to the text section, I assumed it was the reason for the segmentation fault. Seriously, a seg fault in your emulator is a bug in the emulator! Mikey is likely right here. I've (unfortunately) done a lot of emulator work, and every time I've hit a problem like this, the problem has been with the emulator or the emulation environment. Have you isolated the faulting instruction, verified that it's to a reasonable address, and tried examining memory at the faulting address using your emulator's command interface? I'm not sure how this is dealt with on real hardware. The CPU seg faults... :-P But only if the page is mapped non-writeable. Even with the MMU on, Linux maps itself in as writeable. It's the OS, it can do whatever it wants. So it just works on real hardware, and it should just work in your emulator. Can somebody please explain how is it supposed to work ? Is it ok to write to text section that you load on real hardware as readonly ? (again, no mmu involved, as it is still turned off, so i'm not sure who's guarding this section against writing) I'm not sure how this works for 32 bit CPUs, so I can't speak to the details of it. For the 64bit MMU, if you're in real mode (MMU off), nothing can stop this from being written. The kernel ignores the elf sections permissions and does it's own mapping but this can only be enforced once the MMU is on. The same is true on 32-bit ppc - the basic MMU architecture is very similar if you have a part that has real mode (i.e. non-booke). There is no way to restrict stores in real mode. -Becky Mikey On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] you wrote: Hello, First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in latest versions, but i assume the code is still the same and just moved to powerpc. There is a piece of code in the early initialization of the 2.6 kernel that identifies the cpu type and then tries to eliminate code that does not apply to the current cpu. This is done by writing nop's over sections of code that are not needed (do_cpu_ftr_fixups in arch/ppc/kernel/misc.S) When I try to run the kernel in a ppc emulator, I get a segmentation fault in do_cpu_ftr_fixups. From examining the section headers of the vmlinux, the text section is marked as readonly. The piece of code above mentioned is trying to write a nop to memory location inside the text section which is readonly, so that explains the sigsegv error. Any segv in the emulator sounds like a bug in the emulator. If the page really is marked read only, then writing to it should cause a page fault. Since the kernel does run on boards with ppc cpu's, can somebody explain how come this is actually working ? Or if/where I am mistaking with my assumptions ? Thank you P.S. please add me in cc in a reply to this message ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
untested, is it correct?
---
duplicate SNDRV_PCM_FMTBIT_S{16,24}_BE
Signed-off-by: Roel Kluin [EMAIL PROTECTED]
---
diff --git a/sound/aoa/codecs/snd-aoa-codec-tas.c
b/sound/aoa/codecs/snd-aoa-codec-tas.c
index 7a16a33..c922505 100644
--- a/sound/aoa/codecs/snd-aoa-codec-tas.c
+++ b/sound/aoa/codecs/snd-aoa-codec-tas.c
@@ -654,15 +654,15 @@ static struct snd_kcontrol_new bass_control = {
static struct transfer_info tas_transfers[] = {
{
/* input */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
- SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
SNDRV_PCM_RATE_48000,
.transfer_in = 1,
},
{
/* output */
- .formats = SNDRV_PCM_FMTBIT_S16_BE | SNDRV_PCM_FMTBIT_S16_BE |
- SNDRV_PCM_FMTBIT_S24_BE | SNDRV_PCM_FMTBIT_S24_BE,
+ .formats = SNDRV_PCM_FMTBIT_S16_LE | SNDRV_PCM_FMTBIT_S16_BE |
+ SNDRV_PCM_FMTBIT_S24_LE | SNDRV_PCM_FMTBIT_S24_BE,
.rates = SNDRV_PCM_RATE_32000 | SNDRV_PCM_RATE_44100 |
SNDRV_PCM_RATE_48000,
.transfer_in = 0,
},
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [MPC7448] machdep_calls
On Mon, 2008-08-18 at 16:17 +0200, Sébastien Chrétien wrote: The mpc7448hpc2 uses a tsi108-bridge. My board uses an IP on a FPGA.. I read the code of mpc7448_hpc2.c. It uses a ioremap in order to iniatilize the tsi108 registers. But I have already initialized MMU with my registers in HEAD_32.S. Do I need to use ioremap in setup_arch() ? Why did you hack head_32.S ? You shouldn't do that... This is common code, not platform code. Ben. 2008/8/18, Michael Ellerman [EMAIL PROTECTED]: On Mon, 2008-08-18 at 13:35 +0200, Sébastien Chrétien wrote: Can somebody explain me the aim of the function setup_arch in the machine_call structure ? Is this MPC7448 anything like an mpc7448hpc2 ? If so maybe you should start by looking at the code for it in: arch/powerpc/platforms/embedded6xx/mpc7448_hpc2.c Even if it's not related, that will give you some idea of what the callbacks are for. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] POWERPC: duplicate test of MACIO_FLAG_SCCB_ON
On Mon, 2008-08-18 at 18:34 -0400, roel kluin wrote: untested, is it correct? Your patch is correct. The bug is quite harmless thankfully :-) Ben. arch/powerpc/include/asm/pmac_feature.h:359: #define MACIO_FLAG_SCCA_ON 0x0001 #define MACIO_FLAG_SCCB_ON 0x0002 --- duplicate test of MACIO_FLAG_SCCB_ON Signed-off-by: Roel Kluin [EMAIL PROTECTED] --- diff --git a/arch/powerpc/platforms/powermac/feature.c b/arch/powerpc/platforms/powermac/feature.c index 5169ecc..e6c0040 100644 --- a/arch/powerpc/platforms/powermac/feature.c +++ b/arch/powerpc/platforms/powermac/feature.c @@ -2677,7 +2677,7 @@ static void __init probe_one_macio(const char *name, const char *compat, int typ macio_chips[i].of_node = node; macio_chips[i].type = type; macio_chips[i].base = base; - macio_chips[i].flags= MACIO_FLAG_SCCB_ON | MACIO_FLAG_SCCB_ON; + macio_chips[i].flags= MACIO_FLAG_SCCA_ON | MACIO_FLAG_SCCB_ON; macio_chips[i].name = macio_names[type]; revp = of_get_property(node, revision-id, NULL); if (revp) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
On Tue, Aug 19, 2008 at 12:25 AM, Becky Bruce [EMAIL PROTECTED] wrote: On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote: In message [EMAIL PROTECTED] you wrote: The mmu is still disabled at this point. What is marked as readonly is the text section of the vmlinux file generated when compiling the kernel. And since the code tries to write to the text section, I assumed it was the reason for the segmentation fault. Seriously, a seg fault in your emulator is a bug in the emulator! Mikey is likely right here. I've (unfortunately) done a lot of emulator work, and every time I've hit a problem like this, the problem has been with the emulator or the emulation environment. Have you isolated the faulting instruction, verified that it's to a reasonable address, and tried examining memory at the faulting address using your emulator's command interface? yes, it's a store instruction. the value to be stored is a nop instruction and the address is inside the text section (it is writing over existing code that is intended for other cpus). I'm not sure how this is dealt with on real hardware. The CPU seg faults... :-P But only if the page is mapped non-writeable. Even with the MMU on, Linux maps itself in as writeable. It's the OS, it can do whatever it wants. So it just works on real hardware, and it should just work in your emulator. I forgot to mention that I'm trying to run directly the vmlinux image in psim emulator. I'm not sure it's even supposed to work this way. Can somebody please explain how is it supposed to work ? Is it ok to write to text section that you load on real hardware as readonly ? (again, no mmu involved, as it is still turned off, so i'm not sure who's guarding this section against writing) I'm not sure how this works for 32 bit CPUs, so I can't speak to the details of it. For the 64bit MMU, if you're in real mode (MMU off), nothing can stop this from being written. The kernel ignores the elf sections permissions and does it's own mapping but this can only be enforced once the MMU is on. The same is true on 32-bit ppc - the basic MMU architecture is very similar if you have a part that has real mode (i.e. non-booke). There is no way to restrict stores in real mode. -Becky Mikey On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] you wrote: Hello, First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in latest versions, but i assume the code is still the same and just moved to powerpc. There is a piece of code in the early initialization of the 2.6 kernel that identifies the cpu type and then tries to eliminate code that does not apply to the current cpu. This is done by writing nop's over sections of code that are not needed (do_cpu_ftr_fixups in arch/ppc/kernel/misc.S) When I try to run the kernel in a ppc emulator, I get a segmentation fault in do_cpu_ftr_fixups. From examining the section headers of the vmlinux, the text section is marked as readonly. The piece of code above mentioned is trying to write a nop to memory location inside the text section which is readonly, so that explains the sigsegv error. Any segv in the emulator sounds like a bug in the emulator. If the page really is marked read only, then writing to it should cause a page fault. Since the kernel does run on boards with ppc cpu's, can somebody explain how come this is actually working ? Or if/where I am mistaking with my assumptions ? Thank you P.S. please add me in cc in a reply to this message ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
It seems like no one else is interested in the subject, so i will talk directly to you. If you say that the cpu also seg faults, it means that the problem is in the code of the linux kernel... :) Sorry, I was only joking. The hardware does _not_ segfault. There is no equivalent to segfault in real hardware. I'm not sure you are completely familiar with this particular piece of code I'm talking about, so just to make sure... On powerpc, in the beggining, it jumps to the early initialization, where it checks cpu type and then does the cpu features fixup, which means that it overwrites with nop's code that is not intended for this particular cpu. This happens on every powerpc cpu (32 bits at least), so if the problem was here, somebody would have reported it at least. So it is supposed to work this way. But in my emulator at least, I can't get the code to write over code and not get a segmentation fault. The emulator (psim, the one that comes with gdb) keeps it from writing to sections that were loaded as readonly. You're saying it happens the same on real hw ? I'm familiar with the code you are talking about... and it works correctly on real hardware (the code is replaced with NOPs) The section notes are just a hints to the loader. In the case of the Linux kernel, it's ignored or can't be enforced by the PPC architecture. Mikey On Mon, Aug 18, 2008 at 11:51 PM, Michael Neuling [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] yo u wrote: The mmu is still disabled at this point. What is marked as readonly is the text section of the vmlinux file generated when compiling the kernel. And since the code tries to write to the text section, I assumed it was the reason for the segmentation fault. Seriously, a seg fault in your emulator is a bug in the emulator! I'm not sure how this is dealt with on real hardware. The CPU seg faults... :-P Can somebody please explain how is it supposed to work ? Is it ok to write to text section that you load on real hardware as readonly ? (again, no mmu involved, as it is still turned off, so i'm not sure who's guarding this section against writing) I'm not sure how this works for 32 bit CPUs, so I can't speak to the details of it. For the 64bit MMU, if you're in real mode (MMU off), nothing can stop this from being written. The kernel ignores the elf sections permissions and does it's own mapping but this can only be enforced once the MMU is on. Mikey On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling [EMAIL PROTECTED] wrot e: In message [EMAIL PROTECTED] you wrote: Hello, First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in latest versions, but i assume the code is still the same and just moved to powerpc. There is a piece of code in the early initialization of the 2.6 kernel that identifies the cpu type and then tries to eliminate code that does not apply to the current cpu. This is done by writing nop's over sections of code that are not needed (do_cpu_ftr_fixups in arch/ppc/kernel/misc.S) When I try to run the kernel in a ppc emulator, I get a segmentation fault in do_cpu_ftr_fixups. From examining the section headers of the vmlinux, the text section is marked as readonly. The piece of code above mentioned is trying to write a nop to memory location inside the text section which is readonly, so that explains the sigsegv error. Any segv in the emulator sounds like a bug in the emulator. If the page really is marked read only, then writing to it should cause a page fault. Since the kernel does run on boards with ppc cpu's, can somebody explain how come this is actually working ? Or if/where I am mistaking with my assumptions ? Thank you P.S. please add me in cc in a reply to this message ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errrata
A published errata for ppc440epx states, that when running Linux with both
EHCI and OHCI modules loaded, the EHCI module experiences a fatal error
when a high-speed device is connected to the USB2.0, and functions normally
if OHCI module is not loaded.
Quote from original descriprion:
The 440EPx USB 2.0 Host controller is an EHCI compliant controller. In USB
2.0 Host controllers, each EHCI controller has one or more companion
controllers, which may be OHCI or UHCI. An USB 2.0 Host controller will
contain one or more ports. For each port, only one of the controllers is
connected at any one time. In the 440EPx, there is only one OHCI companion
controller,
and only one USB 2.0 Host port.
All ports on an USB 2.0 controller default to the companion controller. If
you load only an ohci driver, it will have control of the ports and any
deviceplugged in will operate, although high speed devices will be forced to
operate at full speed. When an ehci driver is loaded, it explicitly takes
control
of the ports. If there is a device connected, and / or every time there is a
new device connected, the ehci driver determines if the device is high speed or
not. If it is high speed, the driver retains control of the port. If it
is not, the driver explicitly gives the companion controller control of the
port.
There is a software workaround that uses a trick to detect if full-speed
interface
is enabled from the hi-speed driver(and vice versa), and use suspend control
for ohci
to enable/disable it appropriately.
Initial version of the software workaround was posted to linux-usb-devel:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg54019.html
and later were made available from amcc.com:
http://www.amcc.com/Embedded/Downloads/download.html?cat=1family=15ins=2
The patch below is generally based on the latter, but reworked to
powerpc/of_device USB drivers, and uses a few devicetree inquiries to get
rid of (some) hardcoded defines.
Cc: Mark Miesfeld [EMAIL PROTECTED]
Signed-off-by: Vitaly Bordug [EMAIL PROTECTED]
Signed-off-by: Stefan Roese [EMAIL PROTECTED]
---
drivers/usb/host/Kconfig | 16 +
drivers/usb/host/ehci-hub.c| 15
drivers/usb/host/ehci-ppc-of.c | 72
drivers/usb/host/ohci-ppc-of.c | 30 +
4 files changed, 132 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig
index c74de1a..de9a415 100644
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@ -71,6 +71,22 @@ config USB_EHCI_TT_NEWSCHED
If unsure, say N.
+config USB_PPC440EPX_USBH_23_ERRATA
+ bool PPC440EPX USBH_23 ERRATA EHCI and OHCI contention
+ depends on USB_EHCI_HCD 440EPX
+ default y
+ ---help---
+ Allows the EHCI and OHCI drivers to be loaded together when using
+ the USB Host controller on the 440EPX processor. This is necessary
+ when both high speed or full speed devices may be connected to the
+ USB Host port.
+
+ The option is not needed if the USB Host port is only used with
+ USB 2.0 high speed devices and the OHCI driver is never loaded.
+
+ Say N when the OHCI driver for the 440EPX will never be loaded. If
+ unsure, say Y.
+
config USB_EHCI_BIG_ENDIAN_MMIO
bool
depends on USB_EHCI_HCD (PPC_CELLEB || PPC_PS3 || 440EPX ||
ARCH_IXP4XX)
diff --git a/drivers/usb/host/ehci-hub.c b/drivers/usb/host/ehci-hub.c
index 740835b..f012f05 100644
--- a/drivers/usb/host/ehci-hub.c
+++ b/drivers/usb/host/ehci-hub.c
@@ -396,6 +396,10 @@ static inline void remove_companion_file(struct ehci_hcd
*ehci)
/*-*/
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+static void set_ohci_hcfs(int);
+#endif
+
static int check_reset_complete (
struct ehci_hcd *ehci,
int index,
@@ -424,8 +428,17 @@ static int check_reset_complete (
port_status = ~PORT_RWC_BITS;
ehci_writel(ehci, port_status, status_reg);
- } else
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ /* ensure 440EPX ohci controller state is operational */
+ set_ohci_hcfs(1);
+#endif
+ } else {
ehci_dbg (ehci, port %d high speed\n, index + 1);
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+ /* ensure 440EPx ohci controller state is suspended */
+ set_ohci_hcfs(0);
+#endif
+ }
return port_status;
}
diff --git a/drivers/usb/host/ehci-ppc-of.c b/drivers/usb/host/ehci-ppc-of.c
index b018dee..90810f6 100644
--- a/drivers/usb/host/ehci-ppc-of.c
+++ b/drivers/usb/host/ehci-ppc-of.c
@@ -17,6 +17,32 @@
#include linux/of.h
#include linux/of_platform.h
+#ifdef CONFIG_USB_PPC440EPX_USBH_23_ERRATA
+static u32 __iomem *ohci_hcctrl_reg;
+
+#define OHCI_CTRL_HCFS (3 6)
+#define OHCI_USB_OPER (2 6)
Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
Michael Neuling wrote: It seems like no one else is interested in the subject, so i will talk directly to you. If you say that the cpu also seg faults, it means that the problem is in the code of the linux kernel... :) Sorry, I was only joking. The hardware does _not_ segfault. There is no equivalent to segfault in real hardware. Well, there are machine checks and checkstops... :-) -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
In message [EMAIL PROTECTED] you wrote: Michael Neuling wrote: It seems like no one else is interested in the subject, so i will talk directly to you. If you say that the cpu also seg faults, it means that the problem is in the code of the linux kernel... :) Sorry, I was only joking. The hardware does _not_ segfault. There is no equivalent to segfault in real hardware. Well, there are machine checks and checkstops... :-) S! :-) Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: self-modifying code in 2.6 kernel for ppc writes into readonly section
In message [EMAIL PROTECTED] you wr ote: On Tue, Aug 19, 2008 at 12:25 AM, Becky Bruce [EMAIL PROTECTED] wro te: On Aug 18, 2008, at 3:51 PM, Michael Neuling wrote: In message [EMAIL PROTECTED] you wrote: The mmu is still disabled at this point. What is marked as readonly is the text section of the vmlinux file generated when compiling the kernel. And since the code tries to write to the text section, I assumed it was the reason for the segmentation fault. Seriously, a seg fault in your emulator is a bug in the emulator! Mikey is likely right here. I've (unfortunately) done a lot of emulator work, and every time I've hit a problem like this, the problem has been wit h the emulator or the emulation environment. Have you isolated the faulting instruction, verified that it's to a reasonable address, and tried examinin g memory at the faulting address using your emulator's command interface? yes, it's a store instruction. the value to be stored is a nop instruction and the address is inside the text section (it is writing over existing code that is intended for other cpus). I'm not sure how this is dealt with on real hardware. The CPU seg faults... :-P But only if the page is mapped non-writeable. Even with the MMU on, Linux maps itself in as writeable. It's the OS, it can do whatever it wants. So it just works on real hardware, and it should just work in your emulator. I forgot to mention that I'm trying to run directly the vmlinux image in psim emulator. I'm not sure it's even supposed to work this way. Looking at the psim web page quickly, it seems to be for userspace binaries. So yeah, I don't think it's designed to be used like you are try to use it. Can somebody please explain how is it supposed to work ? Is it ok to write to text section that you load on real hardware as readonly ? (again, no mmu involved, as it is still turned off, so i'm not sure who's guarding this section against writing) I'm not sure how this works for 32 bit CPUs, so I can't speak to the details of it. For the 64bit MMU, if you're in real mode (MMU off), nothing can stop this from being written. The kernel ignores the elf sections permissions and does it's own mapping but this can only be enforced once the MMU is on. The same is true on 32-bit ppc - the basic MMU architecture is very similar if you have a part that has real mode (i.e. non-booke). There is no way to restrict stores in real mode. -Becky Mikey On Mon, Aug 18, 2008 at 10:19 PM, Michael Neuling [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED] you wrote: Hello, First, I'm talkin about the 2.6.11 version. I know arch/ppc is gone in latest versions, but i assume the code is still the same and just moved to powerpc. There is a piece of code in the early initialization of the 2.6 kernel that identifies the cpu type and then tries to eliminate code that does not apply to the current cpu. This is done by writing nop's over sections of code that are not needed (do_cpu_ftr_fixups in arch/ppc/kernel/misc.S) When I try to run the kernel in a ppc emulator, I get a segmentation fault in do_cpu_ftr_fixups. From examining the section headers of the vmlinux, the text section is marked as readonly. The piece of code above mentioned is trying to write a nop to memory location inside the text section which is readonly, so that explains the sigsegv error. Any segv in the emulator sounds like a bug in the emulator. If the page really is marked read only, then writing to it should cause a page fault. Since the kernel does run on boards with ppc cpu's, can somebody explain how come this is actually working ? Or if/where I am mistaking with my assumptions ? Thank you P.S. please add me in cc in a reply to this message ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Finding cpuid in entry_64.S
Hello I am trying to find the cpuid when the functions that handle return from context switch and interrupts are called, based on the cpu the return code is executing on, I want to take some specific actions. I have been trying to use the following code segments : LOAD_REG_IMMEDIATE(r13, paca) /* Get base vaddr of paca array */ lhz r6,PACAHWCPUID(r13) /* Load HW procid from paca */ cmpwi 0,r6,7 /* Compare to our id */ My kernel is 2.6.16.21 and I am inserting the above code segments in the file entry_64.S in the following functions: _switch return from system calls, and _ret_from_except I can give line #s and the modified file itself. The problem is my kernel does not boot and halts at the point where it reads the command line boot parameters. Any help would be appreciated . Thanks, Mitesh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Steven Rostedt wrote: Eran Liberty wrote: After compiling a kernel with ftrace I started to experience all sorts of crashes. Just to make sure... ftrace enables markers too, and RCU has tracing with the markers. This may not be the problem, but I just want to eliminate as many variables as possible. Could you disable ftrace, but keep the markers on too. Also, could you enable ftrace again and turn on the FTRACE_STARTUP_TEST. for the fun of it I took out all my propriety modules; so now its a non tainted kernel. Here is the matrix: !FTRACE x !MARKERS = stable !FTRACE x MARKERS = stable FTRACE x !MARKERS = n/a (FTRACE forces MARKERS) FTRACE x MARKERS = unstable FTRACE x FTRACE_STARTUP_TEST x MARKERS = unstable + tests passed Testing tracer sched_switch: PASSED Testing tracer ftrace: PASSED Testing dynamic ftrace: PASSED Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: NIP: c00bbb20 LR: c00bbb20 CTR: REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2) MSR: 00029000 EE,ME CR: 24082282 XER: 2000 TASK = ddcce060[1707] 'find' THREAD: dd5b GPR00: dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b 100234ec GPR08: c080 00019330 dd5b1d20 24000288 100ad874 100936f8 1008a1d0 GPR16: 10083f80 dd5b1e2c dd5b1d68 fff4 c038 dd5b1d60 dd5b1d58 dd802084 GPR24: dc3d7700 dd802018 dd5b1d68 c038 dd801180 dd5b1d68 dd5b1d00 NIP [c00bbb20] d_lookup+0x40/0x90 LR [c00bbb20] d_lookup+0x40/0x90 Call Trace: [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable) [dd5b1d20] [c00aebc4] do_lookup+0xe8/0x220 [dd5b1d50] [c00b0a80] __link_path_walk+0x5a4/0xd54 [dd5b1dc0] [c00b1288] path_walk+0x58/0xe0 [dd5b1df0] [c00b13f8] do_path_lookup+0x78/0x13c [dd5b1e20] [c00b20f4] user_path_at+0x64/0xac [dd5b1e90] [c00a9028] vfs_lstat_fd+0x34/0x74 [dd5b1ec0] [c00a90fc] vfs_lstat+0x30/0x48 [dd5b1ed0] [c00a9144] sys_lstat64+0x30/0x5c [dd5b1f40] [c0010554] ret_from_syscall+0x0/0x3c Instruction dump: 7c0802a6 bf61000c 3f60c038 7c3f0b78 90010024 7c7c1b78 7c9d2378 83db32a0 73c1 7f83e378 7fa4eb78 4082002f 2f83 409e0030 801b32a0 ---[ end trace 1eb8fd7adac2bb65 ]--- Liberty ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Corrections please ...
On Mon, 2008-08-18 at 13:59 -0700, Kevin Diggs wrote: Could I get any needed corrections on this. Especially on the ??? You're missing CC: lkml. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Mohan Kumar M writes: If you need, I can give the .config I use. Yes please, send it over. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] hotplug/rpaphp: remove unused error path code
Commit f46753c5e354b857b20ab8e0fe7b2579831dc369 (PCI: introduce pci_slot) removed the need for this error path. Eliminate this warning: drivers/pci/hotplug/rpaphp_slot.c: In function 'rpaphp_register_slot': drivers/pci/hotplug/rpaphp_slot.c:151: warning: label 'sysfs_fail' defined but not used Signed-off-by: Stephen Rothwell [EMAIL PROTECTED] --- drivers/pci/hotplug/rpaphp_slot.c |4 1 files changed, 0 insertions(+), 4 deletions(-) diff --git a/drivers/pci/hotplug/rpaphp_slot.c b/drivers/pci/hotplug/rpaphp_slot.c index 9b714ea..5088450 100644 --- a/drivers/pci/hotplug/rpaphp_slot.c +++ b/drivers/pci/hotplug/rpaphp_slot.c @@ -147,9 +147,5 @@ int rpaphp_register_slot(struct slot *slot) list_add(slot-rpaphp_slot_list, rpaphp_slot_head); info(Slot [%s] registered\n, slot-name); return 0; - -sysfs_fail: - pci_hp_deregister(php_slot); - return retval; } -- 1.5.6.3 -- Cheers, Stephen Rothwell[EMAIL PROTECTED] http://www.canb.auug.org.au/~sfr/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 2008-08-18 at 11:07 -0400, Steven Rostedt wrote: Eran Liberty wrote: After compiling a kernel with ftrace I started to experience all sorts of crashes. Just to make sure... ftrace enables markers too, and RCU has tracing with the markers. This may not be the problem, but I just want to eliminate as many variables as possible. Could you disable ftrace, but keep the markers on too. Also, could you enable ftrace again and turn on the FTRACE_STARTUP_TEST. I spent some time last week tracking one of those crashes and it appears that we are getting corruption of some of the non-volatile registers. So far, I found out that it -seems- to be coming from stack frame corruption during a timer interrupt. I haven't had a chance to dig further yet. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Oops: Exception in kernel mode, sig: 11 [#1] Exsw1600 Modules linked in: NIP: c00bbb20 LR: c00bbb20 CTR: REGS: dd5b1c50 TRAP: 0700 Not tainted (2.6.27-rc2) MSR: 00029000 EE,ME CR: 24082282 XER: 2000 TASK = ddcce060[1707] 'find' THREAD: dd5b GPR00: dd5b1d00 ddcce060 dd801180 dd5b1d68 dd5b1d58 dd80125b 100234ec GPR08: c080 00019330 dd5b1d20 24000288 100ad874 100936f8 1008a1d0 GPR16: 10083f80 dd5b1e2c dd5b1d68 fff4 c038 dd5b1d60 dd5b1d58 dd802084 GPR24: dc3d7700 dd802018 dd5b1d68 c038 dd801180 dd5b1d68 dd5b1d00 NIP [c00bbb20] d_lookup+0x40/0x90 LR [c00bbb20] d_lookup+0x40/0x90 Call Trace: [dd5b1d00] [dd5b1d58] 0xdd5b1d58 (unreliable) Can you check if, at some point during the system execution (starting from boot), 0xdd5b1d58 is an address where a module is loaded ? (the module can be later unloaded, what I wonder is if this address would appear to have had a loaded+unloaded module). Actually, could you try to compile your kernel without MODULE_UNLOAD ? I've had similar crashes (with similar backtraces in the VFS) on machines with no modules, netbooted zImages. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Finding cpuid in entry_64.S
On Mon, 2008-08-18 at 17:33 -0600, Mitesh R. Meswani wrote: Hello I am trying to find the cpuid when the functions that handle return from context switch and interrupts are called, based on the cpu the return code is executing on, I want to take some specific actions. What are you trying to do more precisely ? It sounds like the wrong solution to whatever problem you have ... Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 2008-08-18 at 14:27 -0400, Steven Rostedt wrote: On Mon, 18 Aug 2008, Scott Wood wrote: Mathieu Desnoyers wrote: asm volatile ( 1: lwz %1, 0(%2)\n cmpw%1, %5\n bne 2f\n stwu%3, 0(%2)\n 2:\n .section .fixup, \ax\\n 3: li %0, 1\n b 2b\n .previous\n .section __ex_table,\a\\n _ASM_ALIGN \n _ASM_PTR 1b, 3b\n .previous : =r(faulted), =r(replaced) : r(ip), r(new), 0(faulted), r(old) : memory); Some (most likely unrelated) nits in the above inline asm: Why not use __get_user/__put_user ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][USB] powerpc: Workaround for the PPC440EPX USBH_23 errrata
.../... There is a software workaround that uses a trick to detect if full-speed interface is enabled from the hi-speed driver(and vice versa), and use suspend control for ohci to enable/disable it appropriately. Initial version of the software workaround was posted to linux-usb-devel: http://www.mail-archive.com/[EMAIL PROTECTED]/msg54019.html and later were made available from amcc.com: http://www.amcc.com/Embedded/Downloads/download.html?cat=1family=15ins=2 The patch below is generally based on the latter, but reworked to powerpc/of_device USB drivers, and uses a few devicetree inquiries to get rid of (some) hardcoded defines. Well, it seems to still call things based on #ifdef CONFIG_* instead of testing for whatever errata bit or flag you can initialize. A proper approach is to have the OF probe code detect via some device-tree compatible testing or such, that it's indeed hitting the broken chip, use that to set a quirk in the controller, and then have the core ehci-hub.c code do whatever it has to do based on the presence of that quirk. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote: On Mon, 2008-08-18 at 14:27 -0400, Steven Rostedt wrote: On Mon, 18 Aug 2008, Scott Wood wrote: Mathieu Desnoyers wrote: asm volatile ( 1: lwz %1, 0(%2)\n cmpw%1, %5\n bne 2f\n stwu%3, 0(%2)\n 2:\n .section .fixup, \ax\\n 3: li %0, 1\n b 2b\n .previous\n .section __ex_table,\a\\n _ASM_ALIGN \n _ASM_PTR 1b, 3b\n .previous : =r(faulted), =r(replaced) : r(ip), r(new), 0(faulted), r(old) : memory); Some (most likely unrelated) nits in the above inline asm: Why not use __get_user/__put_user ? Hmm, this was originally copied from x86, where we did a cmpxchg, but that is probably not needed since all of this is done in kstop_machine. Also, only the get is needed. If we don't fault there, we wont fault on the put (unless we have permissions wrong, and that would be a bug). So are you recommending something like int cmd; if (__get_user(cmd, ip)) goto fault; if (cmd != old) goto not_same; WARN_ON_ONCE(__put_user(cmd, ip)); If we did this, we could probably put this into the generic code: if (copy_from_user(cmd, ip, ARCH_CALL_SIZE)) goto fault; if (memcmp(cmd, old, ARCH_CALL_SIZE) != 0) goto not_same; WARN_ON_ONCE(copy_to_user(cmd, ip, ARCH_CALL_SIZE)); -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Hmm, this was originally copied from x86, where we did a cmpxchg, but that is probably not needed since all of this is done in kstop_machine. Also, only the get is needed. If we don't fault there, we wont fault on the put (unless we have permissions wrong, and that would be a bug). Would it ? How do we make sure the kernel text is mapped writeable ? So are you recommending something like int cmd; if (__get_user(cmd, ip)) goto fault; if (cmd != old) goto not_same; WARN_ON_ONCE(__put_user(cmd, ip)); If we did this, we could probably put this into the generic code: That would work I suppose, I'll give it a try. if (copy_from_user(cmd, ip, ARCH_CALL_SIZE)) goto fault; if (memcmp(cmd, old, ARCH_CALL_SIZE) != 0) goto not_same; WARN_ON_ONCE(copy_to_user(cmd, ip, ARCH_CALL_SIZE)); You need the __ variants or the access_ok() checks will bite you bad. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote: Hmm, this was originally copied from x86, where we did a cmpxchg, but that is probably not needed since all of this is done in kstop_machine. Also, only the get is needed. If we don't fault there, we wont fault on the put (unless we have permissions wrong, and that would be a bug). Would it ? How do we make sure the kernel text is mapped writeable ? We map it writeable if FTRACE is enabled. So are you recommending something like int cmd; if (__get_user(cmd, ip)) goto fault; if (cmd != old) goto not_same; WARN_ON_ONCE(__put_user(cmd, ip)); If we did this, we could probably put this into the generic code: That would work I suppose, I'll give it a try. if (copy_from_user(cmd, ip, ARCH_CALL_SIZE)) goto fault; if (memcmp(cmd, old, ARCH_CALL_SIZE) != 0) goto not_same; WARN_ON_ONCE(copy_to_user(cmd, ip, ARCH_CALL_SIZE)); You need the __ variants or the access_ok() checks will bite you bad. Ah, good point ;-) -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
* Steven Rostedt ([EMAIL PROTECTED]) wrote: On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote: Hmm, this was originally copied from x86, where we did a cmpxchg, but that is probably not needed since all of this is done in kstop_machine. Also, only the get is needed. If we don't fault there, we wont fault on the put (unless we have permissions wrong, and that would be a bug). Would it ? How do we make sure the kernel text is mapped writeable ? We map it writeable if FTRACE is enabled. Argh. See text_poke(). It's there exactly for this purpose on x86. Mathieu So are you recommending something like int cmd; if (__get_user(cmd, ip)) goto fault; if (cmd != old) goto not_same; WARN_ON_ONCE(__put_user(cmd, ip)); If we did this, we could probably put this into the generic code: That would work I suppose, I'll give it a try. if (copy_from_user(cmd, ip, ARCH_CALL_SIZE)) goto fault; if (memcmp(cmd, old, ARCH_CALL_SIZE) != 0) goto not_same; WARN_ON_ONCE(copy_to_user(cmd, ip, ARCH_CALL_SIZE)); You need the __ variants or the access_ok() checks will bite you bad. Ah, good point ;-) -- Steve -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
Ok, so i did a patch, but it doesn't fix the problem. So
there's something else whacking on the stack frames.
Still, here it is:
powerpc/ftrace: Fix broken assembly for code replacement
Instead, uses __get_user() and __put_user().
Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
Index: linux-work/arch/powerpc/kernel/ftrace.c
===
--- linux-work.orig/arch/powerpc/kernel/ftrace.c2008-08-19
12:45:49.0 +1000
+++ linux-work/arch/powerpc/kernel/ftrace.c 2008-08-19 12:52:51.0
+1000
@@ -16,7 +16,7 @@
#include asm/cacheflush.h
#include asm/ftrace.h
-
+#include asm/uaccess.h
static unsigned int ftrace_nop = 0x6000;
@@ -72,10 +72,9 @@ notrace int
ftrace_modify_code(unsigned long ip, unsigned char *old_code,
unsigned char *new_code)
{
- unsigned replaced;
- unsigned old = *(unsigned *)old_code;
- unsigned new = *(unsigned *)new_code;
- int faulted = 0;
+ unsigned int old = *(unsigned int *)old_code;
+ unsigned int new = *(unsigned int *)new_code;
+ unsigned int instr;
/*
* Note: Due to modules and __init, code can
@@ -85,32 +84,13 @@ ftrace_modify_code(unsigned long ip, uns
* No real locking needed, this code is run through
* kstop_machine.
*/
- asm volatile (
- 1: lwz %1, 0(%2)\n
- cmpw%1, %5\n
- bne 2f\n
- stwu%3, 0(%2)\n
- 2:\n
- .section .fixup, \ax\\n
- 3: li %0, 1\n
- b 2b\n
- .previous\n
- .section __ex_table,\a\\n
- _ASM_ALIGN \n
- _ASM_PTR 1b, 3b\n
- .previous
- : =r(faulted), =r(replaced)
- : r(ip), r(new),
- 0(faulted), r(old)
- : memory);
-
- if (replaced != old replaced != new)
- faulted = 2;
-
- if (!faulted)
- flush_icache_range(ip, ip + 8);
-
- return faulted;
+ if (__get_user(instr, (unsigned int __user *)ip))
+ return 1;
+ if (instr != old instr != new)
+ return 2;
+ WARN_ON_ONCE(__put_user(new, (unsigned int __user *)ip));
+ flush_icache_range(ip, ip + 8);
+ return 0;
}
notrace int ftrace_update_ftrace_func(ftrace_func_t func)
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote: Ok, so i did a patch, but it doesn't fix the problem. So there's something else whacking on the stack frames. Is it 32 bit or 64? I've tested the 64 bit quite a bit, but not so much the 32 (my powerbook is not usually that stable). You might want to look at the entry.S mcount code too. Still, here it is: Thanks, powerpc/ftrace: Fix broken assembly for code replacement Instead, uses __get_user() and __put_user(). Acked-by: Steven Rostedt [EMAIL PROTECTED] -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 18 Aug 2008, Mathieu Desnoyers wrote: * Steven Rostedt ([EMAIL PROTECTED]) wrote: On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote: Hmm, this was originally copied from x86, where we did a cmpxchg, but that is probably not needed since all of this is done in kstop_machine. Also, only the get is needed. If we don't fault there, we wont fault on the put (unless we have permissions wrong, and that would be a bug). Would it ? How do we make sure the kernel text is mapped writeable ? We map it writeable if FTRACE is enabled. Argh. See text_poke(). It's there exactly for this purpose on x86. Ouch, I just did. text_poke is quite heavy. It would be interesting to see that performed on 20,000 locations at one time. I could play with it, but I'm a bit nervous. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
* Steven Rostedt ([EMAIL PROTECTED]) wrote: On Mon, 18 Aug 2008, Mathieu Desnoyers wrote: * Steven Rostedt ([EMAIL PROTECTED]) wrote: On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote: Hmm, this was originally copied from x86, where we did a cmpxchg, but that is probably not needed since all of this is done in kstop_machine. Also, only the get is needed. If we don't fault there, we wont fault on the put (unless we have permissions wrong, and that would be a bug). Would it ? How do we make sure the kernel text is mapped writeable ? We map it writeable if FTRACE is enabled. Argh. See text_poke(). It's there exactly for this purpose on x86. Ouch, I just did. text_poke is quite heavy. It would be interesting to see that performed on 20,000 locations at one time. I could play with it, but I'm a bit nervous. It's alread used to modify the LOCK prefixes in alternative.c and did not seem to be too slow for that.. it should therefore be ok. Mathieu -- Steve -- Mathieu Desnoyers OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 18 Aug 2008, Mathieu Desnoyers wrote: Argh. See text_poke(). It's there exactly for this purpose on x86. Ouch, I just did. text_poke is quite heavy. It would be interesting to see that performed on 20,000 locations at one time. I could play with it, but I'm a bit nervous. It's alread used to modify the LOCK prefixes in alternative.c and did not seem to be too slow for that.. it should therefore be ok. There's a lot more functions than locks ;-) Anyway, this is only needed after system boot up. But then we do it ever time we start or stop tracing. I'll try it out and see if it is noticable. -- Steve ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] ibmebus/of_platform: Move name sysfs attribute into generic OF devices
Joachim Fenkes writes: Recent of_platform changes made of_bus_type_init() overwrite the bus type's .dev_attrs list, so move ibmebus' name attribute (which is needed by eHCA userspace support) into generic OF device code. Tested on POWER. Is this a bugfix that is needed for 2.6.27? ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
On Mon, 2008-08-18 at 23:12 -0400, Steven Rostedt wrote: On Tue, 19 Aug 2008, Benjamin Herrenschmidt wrote: Ok, so i did a patch, but it doesn't fix the problem. So there's something else whacking on the stack frames. Is it 32 bit or 64? I've tested the 64 bit quite a bit, but not so much the 32 (my powerbook is not usually that stable). 32-bit. Reproduced on powerbook by a user, 440, 750, ... You might want to look at the entry.S mcount code too. Yeah, I had a look, nothing obviously bad there, but I may just have missed it :-) Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 0/5] Relocatable 64-bit kernel using linker PIE support
Hi Paul, Attaching the .config Paul Mackerras wrote: Mohan Kumar M writes: If you need, I can give the .config I use. Yes please, send it over. # # Automatically generated make config: don't edit # Linux kernel version: 2.6.27-rc1 # Mon Aug 18 14:24:37 2008 # CONFIG_PPC64=y # # Processor support # # CONFIG_POWER4_ONLY is not set CONFIG_POWER3=y CONFIG_POWER4=y # CONFIG_TUNE_CELL is not set CONFIG_PPC_FPU=y CONFIG_ALTIVEC=y # CONFIG_VSX is not set CONFIG_PPC_STD_MMU=y CONFIG_PPC_MM_SLICES=y CONFIG_VIRT_CPU_ACCOUNTING=y CONFIG_SMP=y CONFIG_NR_CPUS=128 CONFIG_64BIT=y CONFIG_WORD_SIZE=64 CONFIG_PPC_MERGE=y CONFIG_MMU=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_HARDIRQS=y CONFIG_HAVE_GET_USER_PAGES_FAST=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_IRQ_PER_CPU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_TRACE_IRQFLAGS_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_ARCH_HAS_ILOG2_U32=y CONFIG_ARCH_HAS_ILOG2_U64=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_ARCH_NO_VIRT_TO_BUS=y CONFIG_PPC=y CONFIG_EARLY_PRINTK=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_PPC_OF=y CONFIG_OF=y CONFIG_PPC_UDBG_16550=y # CONFIG_GENERIC_TBSYNC is not set CONFIG_AUDIT_ARCH=y CONFIG_GENERIC_BUG=y # CONFIG_DEFAULT_UIMAGE is not set # CONFIG_PPC_DCR_NATIVE is not set # CONFIG_PPC_DCR_MMIO is not set # CONFIG_PPC_OF_PLATFORM_PCI is not set CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION= CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y CONFIG_AUDITSYSCALL=y CONFIG_AUDIT_TREE=y CONFIG_IKCONFIG=y CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y CONFIG_CGROUP_DEVICE=y CONFIG_CPUSETS=y # CONFIG_GROUP_SCHED is not set CONFIG_CGROUP_CPUACCT=y # CONFIG_RESOURCE_COUNTERS is not set CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_PROC_PID_CPUSET=y # CONFIG_RELAY is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_IPC_NS is not set # CONFIG_USER_NS is not set # CONFIG_PID_NS is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y # CONFIG_COMPAT_BRK is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_PROFILING=y CONFIG_MARKERS=y CONFIG_OPROFILE=y CONFIG_HAVE_OPROFILE=y CONFIG_KPROBES=y CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_KRETPROBES=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_USE_GENERIC_SMP_HELPERS=y # CONFIG_HAVE_CLK is not set CONFIG_PROC_PAGE_MONITOR=y # CONFIG_HAVE_GENERIC_DMA_COHERENT is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_MODULES=y # CONFIG_MODULE_FORCE_LOAD is not set CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_MODVERSIONS=y CONFIG_MODULE_SRCVERSION_ALL=y CONFIG_KMOD=y CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set CONFIG_BLK_DEV_BSG=y # CONFIG_BLK_DEV_INTEGRITY is not set CONFIG_BLOCK_COMPAT=y # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y CONFIG_DEFAULT_AS=y # CONFIG_DEFAULT_DEADLINE is not set # CONFIG_DEFAULT_CFQ is not set # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED=anticipatory CONFIG_CLASSIC_RCU=y # # Platform support # CONFIG_PPC_MULTIPLATFORM=y CONFIG_PPC_PSERIES=y CONFIG_PPC_SPLPAR=y CONFIG_EEH=y CONFIG_SCANLOG=m CONFIG_LPARCFG=y CONFIG_PPC_PSERIES_DEBUG=y # CONFIG_PPC_SMLPAR is not set # CONFIG_PPC_ISERIES is not set # CONFIG_PPC_PMAC is not set # CONFIG_PPC_MAPLE is not set # CONFIG_PPC_PASEMI is not set # CONFIG_PPC_PS3 is not set # CONFIG_PPC_CELL is not set # CONFIG_PPC_CELL_NATIVE is not set # CONFIG_PPC_IBM_CELL_BLADE is not set # CONFIG_PPC_CELLEB is not set # CONFIG_PQ2ADS is not set CONFIG_PPC_NATIVE=y # CONFIG_UDBG_RTAS_CONSOLE is not set CONFIG_XICS=y # CONFIG_IPIC is not set CONFIG_MPIC=y # CONFIG_MPIC_WEIRD is not set CONFIG_PPC_I8259=y #
[PATCH] powerpc/spufs: Remove invalid semicolon after if statement
Signed-off-by: Ilpo Järvinen [EMAIL PROTECTED] --- arch/powerpc/platforms/cell/spufs/sched.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/platforms/cell/spufs/sched.c b/arch/powerpc/platforms/cell/spufs/sched.c index 2deeeba..f7e5af8 100644 --- a/arch/powerpc/platforms/cell/spufs/sched.c +++ b/arch/powerpc/platforms/cell/spufs/sched.c @@ -1030,7 +1030,7 @@ void spuctx_switch_state(struct spu_context *ctx, node = spu-node; if (old_state == SPU_UTIL_USER) atomic_dec(cbe_spu_info[node].busy_spus); - if (new_state == SPU_UTIL_USER); + if (new_state == SPU_UTIL_USER) atomic_inc(cbe_spu_info[node].busy_spus); } } -- 1.5.2.2 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
