Re: {PATCH] Firmware update using the update_flash -f filename results to soft lockup BUG
In message 4e1543b6.9060...@linux.vnet.ibm.com you wrote: Hi , Problem Description: Firmware update using the update_flash -ffilename results to soft lockup BUG FLASH: preparing saved firmware image for flash FLASH: flash image is 50141296 bytes FLASH: performing flash and reboot FLASH: this will take several minutes. Do not power off! BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36] Steps to reproduce: 1. Check the firmware information on the machine (using ASM or lsmcode) 2. Update the system firmware with the update_flash command update_flash -f 01FL350_039_038.img info: Temporary side will be updated with a newer or identical image Projected Flash Update Results: Current T Image: FL350_039 Current P Image: FL350_039 New T Image: FL350_039 New P Image: FL350_039 Flash image ready...rebooting the system... Broadcast message from root@abc (/dev/hvc0) at 5:25 ... The system is going down for reboot NOW! [root@abc /]# Stopping rhsmcertd[ OK ] Stopping atd: [ OK ] Stopping cups: [ OK ] Stopping abrt daemon: [ OK ] Stopping sshd: [ OK ] Shutting down postfix: [ OK ] Stopping rtas_errd (platform error handling) daemon: [ OK ] Stopping crond: [ OK ] Stopping automount: [ OK ] Stopping HAL daemon: [ OK ] Stopping iprdump: [ OK ] Killing mdmonitor: [ OK ]] Stopping system message bus: [ OK ] Stopping rpcbind: [ OK ] Stopping auditd: [ OK ] Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] ip6tables: Flushing firewall rules: [ OK ] ip6tables: Setting chains to policy ACCEPT: filter [ OK ] ip6tables: Unloading modules: [ OK ] iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] Sending all processes the TERM signal... [ OK ] Sending all processes the KILL signal... [ OK ] Saving random seed: [ OK ] Turning off swap: [ OK ] Turning off quotas: [ OK ] Unmounting pipe file systems: [ OK ] Unmounting file systems: [ OK ] init: Re-executing /sbin/init Please stand by while rebooting the system... Restarting system. FLASH: preparing saved firmware image for flash FLASH: flash image is 50141296 bytes FLASH: performing flash and reboot FLASH: this will take several minutes. Do not power off! BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36] This is solved by the following patch Can you please explain how it fixes it? Also you need a signed off by. --- arch/powerpc/kernel/setup-common.c.orig 2011-07-01 22:41:12.952507971 - 0400 +++ arch/powerpc/kernel/setup-common.c2011-07-01 22:48:31.182507915 - 0400 @@ -109,11 +109,12 @@ void machine_shutdown(void) void machine_restart(char *cmd) { machine_shutdown(); - if (ppc_md.restart) - ppc_md.restart(cmd); #ifdef CONFIG_SMP - smp_send_stop(); +smp_send_stop(); Random white space change here. #endif + if (ppc_md.restart) + ppc_md.restart(cmd); + printk(KERN_EMERG System Halted, OK to turn off power\n); local_irq_disable(); while (1) ; Thanks Divya ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: {PATCH] Firmware update using the update_flash -f filename results to soft lockup BUG
On Thursday 07 July 2011 11:42 AM, Michael Neuling wrote: In message4e1543b6.9060...@linux.vnet.ibm.com you wrote: Hi , Problem Description: Firmware update using the update_flash -ffilename results to soft lockup BUG FLASH: preparing saved firmware image for flash FLASH: flash image is 50141296 bytes FLASH: performing flash and reboot FLASH: this will take several minutes. Do not power off! BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36] Steps to reproduce: 1. Check the firmware information on the machine (using ASM or lsmcode) 2. Update the system firmware with the update_flash command update_flash -f 01FL350_039_038.img info: Temporary side will be updated with a newer or identical image Projected Flash Update Results: Current T Image: FL350_039 Current P Image: FL350_039 New T Image: FL350_039 New P Image: FL350_039 Flash image ready...rebooting the system... Broadcast message from root@abc (/dev/hvc0) at 5:25 ... The system is going down for reboot NOW! [root@abc /]# Stopping rhsmcertd[ OK ] Stopping atd: [ OK ] Stopping cups: [ OK ] Stopping abrt daemon: [ OK ] Stopping sshd: [ OK ] Shutting down postfix: [ OK ] Stopping rtas_errd (platform error handling) daemon: [ OK ] Stopping crond: [ OK ] Stopping automount: [ OK ] Stopping HAL daemon: [ OK ] Stopping iprdump: [ OK ] Killing mdmonitor: [ OK ]] Stopping system message bus: [ OK ] Stopping rpcbind: [ OK ] Stopping auditd: [ OK ] Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] ip6tables: Flushing firewall rules: [ OK ] ip6tables: Setting chains to policy ACCEPT: filter [ OK ] ip6tables: Unloading modules: [ OK ] iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] Sending all processes the TERM signal... [ OK ] Sending all processes the KILL signal... [ OK ] Saving random seed: [ OK ] Turning off swap: [ OK ] Turning off quotas: [ OK ] Unmounting pipe file systems: [ OK ] Unmounting file systems: [ OK ] init: Re-executing /sbin/init Please stand by while rebooting the system... Restarting system. FLASH: preparing saved firmware image for flash FLASH: flash image is 50141296 bytes FLASH: performing flash and reboot FLASH: this will take several minutes. Do not power off! BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36] This is solved by the following patch Can you please explain how it fixes it? Here goes the explanation for the fix. The flash update is conducted with an RTAS call. The RTAS calls are serialized by lock_rtas() which uses a spin_lock. Now there is rtasd which keeps scanning for the RTAS events generated on the machine. This is performed via workqueue mechanism. The rtas_event_scan() also uses an RTAS call to scan the events, eventually taking the lock_rtas() before it issues the request. The flash update is an operation which takes long time, and hence while we are at it, anyboy else who wants to make an RTAS call will have to wait until the update is completed. Now in this case, the rtas_event_scan() is being kicked in to check for events and it waits a long time on the spin_lock, getting us a SOFT Lockup. Before the rtas firmware update starts, all other CPUs should be stopped. Which means no other CPU should be in lock_rtas(). We do not want other CPUs execute while FW update is in progress and the system will be rebooted anyway after the update. Also you need a signed off by. Signed-off-by: Divya dipra...@linux.vnet.ibm.com mailto:dipra...@linux.vnet.ibm.com --- arch/powerpc/kernel/setup-common.c.orig 2011-07-01 22:41:12.952507971 - 0400 +++ arch/powerpc/kernel/setup-common.c 2011-07-01 22:48:31.182507915 - 0400 @@ -109,11 +109,12 @@ void machine_shutdown(void) void machine_restart(char *cmd) { machine_shutdown(); - if (ppc_md.restart) - ppc_md.restart(cmd); #ifdef CONFIG_SMP - smp_send_stop(); +smp_send_stop(); Random white space change here. #endif + if (ppc_md.restart) + ppc_md.restart(cmd); + printk(KERN_EMERG System Halted, OK to turn off power\n); local_irq_disable(); while (1) ; Thanks Divya ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.
On P1022DS both ethernet controllers are connected to RGMII PHYs accessible via MDIO bus. Remove fixed-link property from ethernet nodes as they only required when fixed link PHYs without MDIO bus are used. Signed-off-by: Felix Radensky fe...@embedded-sol.com --- arch/powerpc/boot/dts/p1022ds.dts |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/boot/dts/p1022ds.dts b/arch/powerpc/boot/dts/p1022ds.dts index 98d9426..1be9743 100644 --- a/arch/powerpc/boot/dts/p1022ds.dts +++ b/arch/powerpc/boot/dts/p1022ds.dts @@ -412,7 +412,6 @@ fsl,magic-packet; fsl,wake-on-filer; local-mac-address = [ 00 00 00 00 00 00 ]; - fixed-link = 1 1 1000 0 0; phy-handle = phy0; phy-connection-type = rgmii-id; queue-group@0{ @@ -439,7 +438,6 @@ fsl,num_rx_queues = 0x8; fsl,num_tx_queues = 0x8; local-mac-address = [ 00 00 00 00 00 00 ]; - fixed-link = 1 1 1000 0 0; phy-handle = phy1; phy-connection-type = rgmii-id; queue-group@0{ -- 1.7.4.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH 4/4] powerpc: Enable lockup and hung task detectors in pseriesand ppc64 defeconfigs
As a result of changes to Kconfig files, we no longer enable the lockup and hung task detectors. Both are very light weight and provide useful information in the event of a hang, so reenable them. ... +CONFIG_LOCKUP_DETECTOR=y +CONFIG_DETECT_HUNG_TASK=y Is one of thise responsible for generating a kernel stack traceback when a process has been sleeping uninterruptably for a 'long' time? We have a kernel subsystem that has several 'worker' threads, these always sleep uninterruptable (they are shut down by explicit request) and, at times, can be idle for long periods. Perhaps it should be possible to disable the check either on a per-process of per sleep basis? David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
Hi, linux-3.0-rc fails to boot on a power7 system with 1TB ram and 896 CPUs. While the initial boot log shows a soft-lockup [1], the machine is hung after. Dropping into xmon shows the cpus are all struck at: cpu 0xa: Vector: 100 (System Reset) at [c00fae51fae0] pc: c00596b8: .plpar_hcall_norets+0x80/0xd0 lr: c005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210 sp: c00fae51fd60 msr: 80089032 current = 0xc00fae49d990 paca= 0xcebb1900 pid = 0, comm = kworker/0:1 cpu 0x41: Vector: 100 (System Reset) at [c00fac01bae0] pc: c00596b8: .plpar_hcall_norets+0x80/0xd0 lr: c005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210 sp: c00fac01bd60 msr: 80089032 current = 0xc00faefbf210 paca= 0xcebba280 pid = 0, comm = kworker/0:1 cpu 0x21: Vector: 100 (System Reset) at [c00fae9abae0] pc: c00596b8: .plpar_hcall_norets+0x80/0xd0 lr: c005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210 sp: c00fae9abd60 msr: 80089032 current = 0xc00fae998590 paca= 0xcebb5280 pid = 0, comm = kworker/0:1 cpu 0xb8: Vector: 100 (System Reset) at [c00fab3dbae0] pc: c00596b8: .plpar_hcall_norets+0x80/0xd0 lr: c005b9a4: .pseries_dedicated_idle_sleep+0x194/0x210 sp: c00fab3dbd60 msr: 80089032 current = 0xc00fab3a2710 paca= 0xcebccc00 pid = 0, comm = kworker/0:1 .. .. And shows same for all the CPUs. a:mon t [link register ] c005b9a4 .pseries_dedicated_idle_sleep+0x194/0x210 [c00fae51fd60] 134d (unreliable) [c00fae51fe20] c0018b64 .cpu_idle+0x164/0x210 [c00fae51fed0] c05d55b0 .start_secondary+0x348/0x354 [c00fae51ff90] c0009268 .start_secondary_prolog+0x10/0x14 a:mon S msr = 80001032 sprg0= pvr = 003f0201 sprg1= cebb1900 dec = 30fb5b4f sprg2= cebb1900 sp = c00fae51f440 sprg3= 000a toc = c0e21f90 dar = c11aee0c20e8 a:mon 2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae - sched: Change NODE sched_domain group creation as the cause. Thanks, -Mahesh. [1]: POWER7 performance monitor hardware support registered Brought up 896 CPUs Enabling Asymmetric SMT scheduling BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1] Modules linked in: NIP: c0074b90 LR: c008a1c4 CTR: REGS: c00fae25f9c0 TRAP: 0901 Not tainted (3.0.0-rc6) MSR: 80009032 EE,ME,IR,DR CR: 2488 XER: 0004 TASK = c00fae248490[1] 'swapper' THREAD: c00fae25c000 CPU: 0 GPR00: e2a55cbeec50 c00fae25fc40 c0e21f90 c07b2b34cb00 GPR04: 0100 0100 c11adcf23418 GPR08: c08b2b7d4480 c07b2b35ef80 24ac GPR12: 4442 cebb NIP [c0074b90] .update_group_power+0x50/0x190 LR [c008a1c4] .build_sched_domains+0x434/0x490 Call Trace: [c00fae25fc40] [c00fae25fce0] 0xc00fae25fce0 (unreliable) [c00fae25fce0] [c008a1c4] .build_sched_domains+0x434/0x490 [c00fae25fdd0] [c0867370] .sched_init_smp+0xa8/0x224 [c00fae25fee0] [c0850274] .kernel_init+0x10c/0x1fc [c00fae25ff90] [c0023884] .kernel_thread+0x54/0x70 Instruction dump: f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa9 419e0054 e9490010 3800 7d495378 6000 8169000c e929 7faa4800 7c005a14 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
On Thu, 2011-07-07 at 15:52 +0530, Mahesh J Salgaonkar wrote: 2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae - sched: Change NODE sched_domain group creation as the cause. Weird, there's no locking anywhere around there. The typical problems with this patch-set were massive explosions due to bad pointers etc.. But not silent hangs. The code its stuck at: [1]: POWER7 performance monitor hardware support registered Brought up 896 CPUs Enabling Asymmetric SMT scheduling BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1] Modules linked in: NIP: c0074b90 LR: c008a1c4 CTR: REGS: c00fae25f9c0 TRAP: 0901 Not tainted (3.0.0-rc6) MSR: 80009032 EE,ME,IR,DR CR: 2488 XER: 0004 TASK = c00fae248490[1] 'swapper' THREAD: c00fae25c000 CPU: 0 GPR00: e2a55cbeec50 c00fae25fc40 c0e21f90 c07b2b34cb00 GPR04: 0100 0100 c11adcf23418 GPR08: c08b2b7d4480 c07b2b35ef80 24ac GPR12: 4442 cebb NIP [c0074b90] .update_group_power+0x50/0x190 LR [c008a1c4] .build_sched_domains+0x434/0x490 Call Trace: [c00fae25fc40] [c00fae25fce0] 0xc00fae25fce0 (unreliable) [c00fae25fce0] [c008a1c4] .build_sched_domains+0x434/0x490 [c00fae25fdd0] [c0867370] .sched_init_smp+0xa8/0x224 [c00fae25fee0] [c0850274] .kernel_init+0x10c/0x1fc [c00fae25ff90] [c0023884] .kernel_thread+0x54/0x70 Instruction dump: f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa9 419e0054 e9490010 3800 7d495378 6000 8169000c e929 7faa4800 7c005a14 doesn't contains any locks, its simply looping over all the cpus, and with that many I can imagine it takes a while, but getting 'stuck' there is unexpected to say the least. Surely this isn't the first multi-node P7 to boot a kernel with this patch? If my git foo is any good it hit -next on 23rd of May. I guess I'm asking is, do smaller P7 machines boot? And if so, is there any difference except size? How many nodes does the thing have anyway, 28? Hmm, that could mean its the first machine with 16 nodes to boot this, which would make it trigger the magic ALL_NODES crap. Let me dig around there. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
On 2011-07-07 12:59:35 Thu, Peter Zijlstra wrote: On Thu, 2011-07-07 at 15:52 +0530, Mahesh J Salgaonkar wrote: 2.6.39 booted fine on the system and a git bisect shows commit cd4ea6ae - sched: Change NODE sched_domain group creation as the cause. Weird, there's no locking anywhere around there. The typical problems with this patch-set were massive explosions due to bad pointers etc.. But not silent hangs. The code its stuck at: [1]: POWER7 performance monitor hardware support registered Brought up 896 CPUs Enabling Asymmetric SMT scheduling BUG: soft lockup - CPU#0 stuck for 22s! [swapper:1] Modules linked in: NIP: c0074b90 LR: c008a1c4 CTR: REGS: c00fae25f9c0 TRAP: 0901 Not tainted (3.0.0-rc6) MSR: 80009032 EE,ME,IR,DR CR: 2488 XER: 0004 TASK = c00fae248490[1] 'swapper' THREAD: c00fae25c000 CPU: 0 GPR00: e2a55cbeec50 c00fae25fc40 c0e21f90 c07b2b34cb00 GPR04: 0100 0100 c11adcf23418 GPR08: c08b2b7d4480 c07b2b35ef80 24ac GPR12: 4442 cebb NIP [c0074b90] .update_group_power+0x50/0x190 LR [c008a1c4] .build_sched_domains+0x434/0x490 Call Trace: [c00fae25fc40] [c00fae25fce0] 0xc00fae25fce0 (unreliable) [c00fae25fce0] [c008a1c4] .build_sched_domains+0x434/0x490 [c00fae25fdd0] [c0867370] .sched_init_smp+0xa8/0x224 [c00fae25fee0] [c0850274] .kernel_init+0x10c/0x1fc [c00fae25ff90] [c0023884] .kernel_thread+0x54/0x70 Instruction dump: f821ff61 ebc2b1a0 7c7f1b78 7c9c2378 e9230008 eba30010 2fa9 419e0054 e9490010 3800 7d495378 6000 8169000c e929 7faa4800 7c005a14 doesn't contains any locks, its simply looping over all the cpus, and with that many I can imagine it takes a while, but getting 'stuck' there is unexpected to say the least. Surely this isn't the first multi-node P7 to boot a kernel with this patch? If my git foo is any good it hit -next on 23rd of May. I guess I'm asking is, do smaller P7 machines boot? And if so, is there any difference except size? Yes, the smaller P7 machine that I have with 20 CPUs and 2GB ram boots fine with 3.0.0-rc. How many nodes does the thing have anyway, 28? Hmm, that could mean its the first machine with 16 nodes to boot this, which would make it trigger the magic ALL_NODES crap. The P7 machine where kernel fails to boot shows following demsg log w.r.t node map: --- Zone PFN ranges: DMA 0x - 0x01229000 Normal empty Movable zone start PFN for each node early_node_map[12] active PFN ranges 0: 0x - 0x000fd000 4: 0x000fd000 - 0x002fb000 5: 0x002fb000 - 0x004b9000 6: 0x004b9000 - 0x006b9000 8: 0x006b9000 - 0x007b5000 12: 0x007b5000 - 0x008b5000 16: 0x008b5000 - 0x009b1000 20: 0x009b1000 - 0x00bb1000 21: 0x00bb1000 - 0x00db1000 22: 0x00db1000 - 0x00fb1000 23: 0x00fb1000 - 0x011b1000 28: 0x011b1000 - 0x01229000 Could not find start_pfn for node 1 Could not find start_pfn for node 2 Could not find start_pfn for node 3 Could not find start_pfn for node 7 Could not find start_pfn for node 9 Could not find start_pfn for node 10 Could not find start_pfn for node 11 Could not find start_pfn for node 13 Could not find start_pfn for node 14 Could not find start_pfn for node 15 Could not find start_pfn for node 17 Could not find start_pfn for node 18 Could not find start_pfn for node 19 Could not find start_pfn for node 29 Could not find start_pfn for node 30 Could not find start_pfn for node 31 [boot]0015 Setup Done PERCPU: Embedded 1 pages/cpu @c00013c0 s31488 r0 d34048 u65536 Built 28 zonelists in Node order, mobility grouping on. Total pages: 19026032 Policy zone: DMA Kernel command line: root=/dev/mapper/vg_nish1-lv_root ro rd_LVM_LV=vg_nish1/lv_root rd_LVM_LV=VolGroup/lv_swap rd_LVM_LV=vg_nish1/lv_swap rd_NO_LUKS rd_NO_MD rd_NO_DM LANG=en_US.UTF-8 SYSFONT=latarcyrheb-sun16 KEYTABLE=us console=hvc0i memblock=debug PID hash table entries: 4096 (order: -1, 32768 bytes) freeing bootmem node 0 freeing bootmem node 4 freeing bootmem node 5 freeing bootmem node 6 freeing bootmem node 8 freeing bootmem node 12 freeing bootmem node 16 freeing bootmem node 20 freeing bootmem node 21 freeing bootmem node 22 freeing bootmem node 23 freeing bootmem node 28 Memory: 1213775296k/1218707456k available (13312k kernel code, 4932160k reserved, 1600k data, 2727k bss, 4928k init) --- Thanks, -Mahesh. Let me dig around there. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- Mahesh J Salgaonkar ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org
Re: [regression] 3.0-rc boot failure -- bisected to cd4ea6ae3982
On Thu, 2011-07-07 at 17:25 +0530, Mahesh J Salgaonkar wrote: I guess I'm asking is, do smaller P7 machines boot? And if so, is there any difference except size? Yes, the smaller P7 machine that I have with 20 CPUs and 2GB ram boots fine with 3.0.0-rc. That sounds like a single node machine. P7 comes as {4,6,8}*4 (16,24,32 cpus) per socket. And that 2G doesn't sound like much either. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/5200: dts: digsy_mtc.dts: enable both MSCAN nodes
We use both MSCAN controllers on this board, so do not disable them in the device tree. Signed-off-by: Anatolij Gustschin ag...@denx.de --- arch/powerpc/boot/dts/digsy_mtc.dts |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts index 2aad7ae..a7511f2 100644 --- a/arch/powerpc/boot/dts/digsy_mtc.dts +++ b/arch/powerpc/boot/dts/digsy_mtc.dts @@ -37,14 +37,6 @@ status = disabled; }; - can@900 { - status = disabled; - }; - - can@980 { - status = disabled; - }; - spi@f00 { msp430@0 { compatible = spidev; -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata
On Jul 1, 2011, at 5:09 PM, Greg KH wrote: On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote: On some architectures we need to setup pdev_archdata before we add the device. Waiting til a bus_notifier is too late since we might need the pdev_archdata in the bus notifier. One example is setting up of dma_mask pointers such that it can be used in a bus_notifier. We add noop version of arch_setup_pdev_archdata() in asm-generic/platform_device.h and allow the arch code to override with access the full definitions of struct device, struct platform_device, and struct pdev_archdata. Isn't there some way to use weak symbols to keep us from having to create this .h file in every single arch and then if the arch wants to define it, it does so? That should make this patch simpler, right? thanks, greg k-h Changing to weak should be doable if we are ok with the additional function call always happening. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] Remove a BUG_ON that triggered when running under FSL Hypervisor
mpc85xx_smp_init platform init function assumed that smp_ops.message_pass was set to default arch dependent smp_muxed_ipi_message_pass. However this does not seem to happen. Moreover, the arch specific code in arch/powerpc/kernel/smp.c handles smp_ops.message_pass == NULL and if so calls the default implementation. Signed-off-by: Laurentiu TUDOR laurentiu.tu...@freescale.com --- arch/powerpc/platforms/85xx/smp.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) diff --git a/arch/powerpc/platforms/85xx/smp.c b/arch/powerpc/platforms/85xx/smp.c index f5aa619..5b9b901 100644 --- a/arch/powerpc/platforms/85xx/smp.c +++ b/arch/powerpc/platforms/85xx/smp.c @@ -2,7 +2,7 @@ * Author: Andy Fleming aflem...@freescale.com *Kumar Gala ga...@kernel.crashing.org * - * Copyright 2006-2008 Freescale Semiconductor Inc. + * Copyright 2006-2008, 2011 Freescale Semiconductor Inc. * * This program is free software; you can redistribute it and/or modify it * under the terms of the GNU General Public License as published by the @@ -239,12 +239,13 @@ void __init mpc85xx_smp_init(void) } if (cpu_has_feature(CPU_FTR_DBELL)) { - /* .message_pass defaults to smp_muxed_ipi_message_pass */ + /* +* If left NULL, .message_pass defaults to +* smp_muxed_ipi_message_pass +*/ smp_85xx_ops.cause_ipi = doorbell_cause_ipi; } - BUG_ON(!smp_85xx_ops.message_pass); - smp_ops = smp_85xx_ops; #ifdef CONFIG_KEXEC -- 1.6.6 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata
On Thu, Jul 07, 2011 at 08:55:44AM -0500, Kumar Gala wrote: On Jul 1, 2011, at 5:09 PM, Greg KH wrote: On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote: On some architectures we need to setup pdev_archdata before we add the device. Waiting til a bus_notifier is too late since we might need the pdev_archdata in the bus notifier. One example is setting up of dma_mask pointers such that it can be used in a bus_notifier. We add noop version of arch_setup_pdev_archdata() in asm-generic/platform_device.h and allow the arch code to override with access the full definitions of struct device, struct platform_device, and struct pdev_archdata. Isn't there some way to use weak symbols to keep us from having to create this .h file in every single arch and then if the arch wants to define it, it does so? That should make this patch simpler, right? thanks, greg k-h Changing to weak should be doable if we are ok with the additional function call always happening. Given that this is not a fast path, and the function call for the normal case would do nothing, it should be fine, right? greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Analysing a kernel panic
I'll expand a bit on my previous message. Here's a more detailed dump of what happens when my system receives a second interrupt (the 1st one works fine) from my hardware: [ 263.586996] do_IRQ: stack overflow: 1920 [ 263.590785] Call Trace: [ 263.593275] [c7792780] [c00073ac] show_stack+0x80/0x19c (unreliable) [ 263.599543] [c77927c0] [c0004d98] do_IRQ+0x48/0xcc [ 263.604314] [c77927d0] [c000f434] ret_from_except+0x0/0x18 [ 263.609714] [c7792890] [] (null) [ 263.613628] [c77928a0] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.619476] [c7792960] [] (null) [ 263.623410] [c7792970] [c0052554] handle_level_irq+0x54/0x128 [ 263.629090] [c7792980] [c0004dd8] do_IRQ+0x88/0xcc [ 263.633852] [c7792990] [c000f434] ret_from_except+0x0/0x18 [ 263.639262] [c7792a50] [] (null) [ 263.643176] [c7792a60] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.649025] [c7792b20] [] (null) [ 263.652945] [c7792b30] [c0052554] handle_level_irq+0x54/0x128 [ 263.658638] [c7792b40] [c0004dd8] do_IRQ+0x88/0xcc [ 263.663400] [c7792b50] [c000f434] ret_from_except+0x0/0x18 [ 263.668811] [c7792c10] [] (null) [ 263.672725] [c7792c20] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.678574] [c7792ce0] [] (null) [ 263.682494] [c7792cf0] [c0052554] handle_level_irq+0x54/0x128 [ 263.688189] [c7792d00] [c0004dd8] do_IRQ+0x88/0xcc [ 263.692949] [c7792d10] [c000f434] ret_from_except+0x0/0x18 [ 263.698360] [c7792dd0] [] (null) [ 263.702274] [c7792de0] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.708123] [c7792ea0] [] (null) [ 263.712043] [c7792eb0] [c0052554] handle_level_irq+0x54/0x128 [ 263.717736] [c7792ec0] [c0004dd8] do_IRQ+0x88/0xcc [ 263.722498] [c7792ed0] [c000f434] ret_from_except+0x0/0x18 [ 263.727909] [c7792f90] [] (null) [ 263.731822] [c7792fa0] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.737671] [c7793060] [] (null) [ 263.741592] [c7793070] [c0052554] handle_level_irq+0x54/0x128 [ 263.747285] [c7793080] [c0004dd8] do_IRQ+0x88/0xcc [ 263.752048] [c7793090] [c000f434] ret_from_except+0x0/0x18 [ 263.757457] [c7793150] [] (null) [ 263.761372] [c7793160] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.767221] [c7793220] [] (null) [ 263.771143] [c7793230] [c0052554] handle_level_irq+0x54/0x128 [ 263.776834] [c7793240] [c0004dd8] do_IRQ+0x88/0xcc [ 263.781597] [c7793250] [c000f434] ret_from_except+0x0/0x18 [ 263.787006] [c7793310] [] (null) [ 263.790921] [c7793320] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.796770] [c77933e0] [] (null) [ 263.800693] [c77933f0] [c0052554] handle_level_irq+0x54/0x128 [ 263.806383] [c7793400] [c0004dd8] do_IRQ+0x88/0xcc [ 263.811146] [c7793410] [c000f434] ret_from_except+0x0/0x18 [ 263.816555] [c77934d0] [] (null) [ 263.820470] [c77934e0] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.826319] [c77935a0] [] (null) [ 263.830241] [c77935b0] [c0052554] handle_level_irq+0x54/0x128 [ 263.835932] [c77935c0] [c0004dd8] do_IRQ+0x88/0xcc [ 263.840694] [c77935d0] [c000f434] ret_from_except+0x0/0x18 [ 263.846104] [c7793690] [] (null) [ 263.850019] [c77936a0] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.855867] [c7793760] [] (null) [ 263.859788] [c7793770] [c0052554] handle_level_irq+0x54/0x128 [ 263.865481] [c7793780] [c0004dd8] do_IRQ+0x88/0xcc [ 263.870242] [c7793790] [c000f434] ret_from_except+0x0/0x18 [ 263.875653] [c7793850] [] (null) [ 263.879567] [c7793860] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.885416] [c7793920] [] (null) [ 263.889336] [c7793930] [c0052554] handle_level_irq+0x54/0x128 [ 263.895030] [c7793940] [c0004dd8] do_IRQ+0x88/0xcc [ 263.899790] [c7793950] [c000f434] ret_from_except+0x0/0x18 [ 263.905201] [c7793a10] [] (null) [ 263.909115] [c7793a20] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.914971] do_IRQ: stack overflow: 1472 [ 263.918843] Call Trace: [ 263.921304] [c77925c0] [c00073ac] show_stack+0x80/0x19c (unreliable) [ 263.927600] [c7792600] [c0004d98] do_IRQ+0x48/0xcc [ 263.932357] [c7792610] [c000f434] ret_from_except+0x0/0x18 [ 263.937791] [c77926d0] [3b9aca00] 0x3b9aca00 [ 263.942035] [c77926e0] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.947899] [c77927a0] [3b9aca00] 0x3b9aca00 [ 263.952151] [c77927b0] [c0052554] handle_level_irq+0x54/0x128 [ 263.957842] [c77927c0] [c0004dd8] do_IRQ+0x88/0xcc [ 263.962603] [c77927d0] [c000f434] ret_from_except+0x0/0x18 [ 263.968014] [c7792890] [] (null) [ 263.971928] [c77928a0] [c000f3e8] ret_from_except_full+0x0/0x4c [ 263.97] [c7792960] [] (null) [ 263.981697] [c7792970] [c0052554] handle_level_irq+0x54/0x128 [ 263.987390] [c7792980] [c0004dd8] do_IRQ+0x88/0xcc [ 263.992152] [c7792990] [c000f434] ret_from_except+0x0/0x18 [ 263.997563] [c7792a50] [] (null) [ 264.001476] [c7792a60] [c000f3e8] ret_from_except_full+0x0/0x4c [ 264.007326] [c7792b20] [] (null)
Re: [PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.
Felix Radensky wrote: On P1022DS both ethernet controllers are connected to RGMII PHYs accessible via MDIO bus. Remove fixed-link property from ethernet nodes as they only required when fixed link PHYs without MDIO bus are used. Signed-off-by: Felix Radensky fe...@embedded-sol.com Acked-by: Timur Tabi ti...@freescale.com Ethernet works before and after applying this patch, so all I can say is that it doesn't break anything. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc,ppc4xx_edac: Add comma to fix build error
Commit 4018294b53d1dae026880e45f174c1cc63b5d435 broke the ppc4xx_edac driver at line 210 where the struct member is missing a comma. Signed-off-by: Mike Williams m...@mikebwilliams.com --- drivers/edac/ppc4xx_edac.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/edac/ppc4xx_edac.c b/drivers/edac/ppc4xx_edac.c index b9f0c20..446b5c0 100644 --- a/drivers/edac/ppc4xx_edac.c +++ b/drivers/edac/ppc4xx_edac.c @@ -206,7 +206,7 @@ static struct of_platform_driver ppc4xx_edac_driver = { .remove = ppc4xx_edac_remove, .driver = { .owner = THIS_MODULE, - .name = PPC4XX_EDAC_MODULE_NAME + .name = PPC4XX_EDAC_MODULE_NAME, .of_match_table = ppc4xx_edac_match, }, }; -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] drivers/video: use strings to specify the Freescale DIU monitor port
Instead of using ill-defined numbers (0, 1, and 2) for the monitor port, allow the user to specify the port by name (dvi, lvds, or dlvds). This works on the kernel command line, the module command-line, and the sysfs monitor device. Note that changing the monitor port does not currently work on the P1022DS, because the code that talks to the PIXIS FPGA is broken. Signed-off-by: Timur Tabi ti...@freescale.com --- arch/powerpc/platforms/512x/mpc512x_shared.c | 22 +++- arch/powerpc/platforms/85xx/p1022_ds.c | 47 - arch/powerpc/platforms/86xx/mpc8610_hpcd.c | 55 +--- arch/powerpc/sysdev/fsl_soc.h| 25 ++--- drivers/video/fsl-diu-fb.c | 73 +++-- 5 files changed, 128 insertions(+), 94 deletions(-) diff --git a/arch/powerpc/platforms/512x/mpc512x_shared.c b/arch/powerpc/platforms/512x/mpc512x_shared.c index e41ebbd..3dc62f9 100644 --- a/arch/powerpc/platforms/512x/mpc512x_shared.c +++ b/arch/powerpc/platforms/512x/mpc512x_shared.c @@ -66,8 +66,8 @@ struct fsl_diu_shared_fb { boolin_use; }; -unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel, - int monitor_port) +u32 mpc512x_get_pixel_format(enum fsl_diu_monitor_port port, +unsigned int bits_per_pixel) { switch (bits_per_pixel) { case 32: @@ -80,11 +80,12 @@ unsigned int mpc512x_get_pixel_format(unsigned int bits_per_pixel, return 0x0400; } -void mpc512x_set_gamma_table(int monitor_port, char *gamma_table_base) +void mpc512x_set_gamma_table(enum fsl_diu_monitor_port port, +char *gamma_table_base) { } -void mpc512x_set_monitor_port(int monitor_port) +void mpc512x_set_monitor_port(enum fsl_diu_monitor_port port) { } @@ -182,14 +183,10 @@ void mpc512x_set_pixel_clock(unsigned int pixclock) iounmap(ccm); } -ssize_t mpc512x_show_monitor_port(int monitor_port, char *buf) +enum fsl_diu_monitor_port +mpc512x_valid_monitor_port(enum fsl_diu_monitor_port port) { - return sprintf(buf, 0 - 5121 LCD\n); -} - -int mpc512x_set_sysfs_monitor_port(int val) -{ - return 0; + return FSL_DIU_PORT_DVI; } static struct fsl_diu_shared_fb __attribute__ ((__aligned__(8))) diu_shared_fb; @@ -332,8 +329,7 @@ void __init mpc512x_setup_diu(void) diu_ops.set_gamma_table = mpc512x_set_gamma_table; diu_ops.set_monitor_port= mpc512x_set_monitor_port; diu_ops.set_pixel_clock = mpc512x_set_pixel_clock; - diu_ops.show_monitor_port = mpc512x_show_monitor_port; - diu_ops.set_sysfs_monitor_port = mpc512x_set_sysfs_monitor_port; + diu_ops.valid_monitor_port = mpc512x_valid_monitor_port; diu_ops.release_bootmem = mpc512x_release_bootmem; #endif } diff --git a/arch/powerpc/platforms/85xx/p1022_ds.c b/arch/powerpc/platforms/85xx/p1022_ds.c index 266b3aa..c01c727 100644 --- a/arch/powerpc/platforms/85xx/p1022_ds.c +++ b/arch/powerpc/platforms/85xx/p1022_ds.c @@ -93,8 +93,8 @@ * The Area Descriptor is a 32-bit value that determine which bits in each * pixel are to be used for each color. */ -static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel, - int monitor_port) +static u32 p1022ds_get_pixel_format(enum fsl_diu_monitor_port port, + unsigned int bits_per_pixel) { switch (bits_per_pixel) { case 32: @@ -118,7 +118,8 @@ static unsigned int p1022ds_get_pixel_format(unsigned int bits_per_pixel, * On some boards, the gamma table for some ports may need to be modified. * This is not the case on the P1022DS, so we do nothing. */ -static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base) +static void p1022ds_set_gamma_table(enum fsl_diu_monitor_port port, + char *gamma_table_base) { } @@ -126,7 +127,7 @@ static void p1022ds_set_gamma_table(int monitor_port, char *gamma_table_base) * p1022ds_set_monitor_port: switch the output to a different monitor port * */ -static void p1022ds_set_monitor_port(int monitor_port) +static void p1022ds_set_monitor_port(enum fsl_diu_monitor_port port) { struct device_node *pixis_node; void __iomem *pixis; @@ -145,19 +146,21 @@ static void p1022ds_set_monitor_port(int monitor_port) } brdcfg1 = pixis + 9;/* BRDCFG1 is at offset 9 in the ngPIXIS */ - switch (monitor_port) { - case 0: /* DVI */ + switch (port) { + case FSL_DIU_PORT_DVI: + printk(KERN_INFO %s:%u\n, __func__, __LINE__); /* Enable the DVI port, disable the DFP and the backlight */ clrsetbits_8(brdcfg1, PX_BRDCFG1_DFPEN | PX_BRDCFG1_BACKLIGHT, PX_BRDCFG1_DVIEN); break; - case 1: /* Single link LVDS */ +
Re: [PATCH] powerpc/5200: dts: digsy_mtc.dts: enable both MSCAN nodes
On Thu, Jul 07, 2011 at 02:49:50PM +0200, Anatolij Gustschin wrote: We use both MSCAN controllers on this board, so do not disable them in the device tree. Signed-off-by: Anatolij Gustschin ag...@denx.de Applied, thanks. g. --- arch/powerpc/boot/dts/digsy_mtc.dts |8 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/arch/powerpc/boot/dts/digsy_mtc.dts b/arch/powerpc/boot/dts/digsy_mtc.dts index 2aad7ae..a7511f2 100644 --- a/arch/powerpc/boot/dts/digsy_mtc.dts +++ b/arch/powerpc/boot/dts/digsy_mtc.dts @@ -37,14 +37,6 @@ status = disabled; }; - can@900 { - status = disabled; - }; - - can@980 { - status = disabled; - }; - spi@f00 { msp430@0 { compatible = spidev; -- 1.7.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc: enable access to HT Host-Bridge on Maple
On Fri, 2011-07-01 at 18:44 +0200, Segher Boessenkool wrote: CPC925/CPC945 use special window to access host bridge functionality of u3-ht. Provide a way to access this device. Why? Is anything going to use it? +static int u3_ht_root_read_config(struct pci_controller *hose, u8 offset, + int len, u32 *val) +{ + volatile void __iomem *addr; + + addr = hose-cfg_addr; + addr += ((offset ~3) 2) + (4 - len - (offset 3)); This will only work for len 1,2,4 with offset a multiple of len, is that guaranteed here? I think the upper layer does. Dbl check tho. hose-cfg_data = ioremap(0xf200, 0x0200); + hose-cfg_addr = ioremap(0xf807, 0x1000); Eww. You could just make a global instead of abusing existing fields, there can be only one CPC9x5 in a system anyway. Nah, that's fine, we abuse it that way regulary :-) Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: Analysing a kernel panic
On Tue, 2011-07-05 at 16:19 +0200, Guillaume Dargaud wrote: Hello all, one of my drivers is causing a kernel panic and I _think_ it happens in the 1st call to the interrupt routine. What kind of information can I extract from the following ? Is it like a core dump that I can load with the executable in the debugger to know exactly what happened (I doubt it) ? Kernel stack overflow in process c6ce80a0, r1=c778c070 That's bad... NIP: c000d270 LR: c000f3c8 CTR: c0017fd0 REGS: c778bfc0 TRAP: 0501 Tainted: G D (2.6.34) MSR: 00029030 EE,ME,CE,IR,DR CR: 2448 XER: TASK = c6ce80a0[241] 'SoftNoy' THREAD: c778c000 GPR00: 00029030 c778c070 c6ce80a0 c778c090 0800 32d8 0001 0001 GPR08: 32da 00021032 c000d110 06ce82a8 NIP [c000d270] program_check_exception+0x160/0x228 LR [c000f3c8] ret_from_except_full+0x0/0x4c Call Trace: Instruction dump: 38090004 901f0080 48d8 3ca3 7fe4fb78 80df0080 60a50001 3865 48a8 7ca6 60008000 7c000124 77c00c04 41a20068 4bffef89 2f83fff2 Kernel panic - not syncing: kernel stack overflow Call Trace: Rebooting in 180 seconds.. My driver is xad.ko, though /dev/xps-acqui-data. The user program is SoftNoy. The code for the ISR (note that this code works fine on the same driver for a slightly different piece of custom hardware): static irqreturn_t XadIsr(int irq, void *dev_id) { Xad.control_reg-fin_in = 0; Xad.interrupt_reg-ISR = 1; Xad.interrupt_IPIF_reg-ISR = 4; Xad.control_reg-flux_address[0] = BUFFER_PHY_BASE + BUF_SZ*(++Xad.Icnt % BUF_NB); Xad.control_reg-flux_address[1] = Xad.control_reg-flux_address[0] + BUF_SZ/2; if (Xad.IcntXad.Rcnt+BUF_NB) Xad.control_reg-flux_start=255;// Arm the next interrupt else { // There aren't any buffers available for the next read. We'll do the start in the read routine Xad.Suspended=1; Xad.OverflowsSinceLastRead++; Xad.Overflow++; DBG_ADD_CHAR('*'); if (Verbose) printk(KERN_WARNING SD %dth buffer overflow: %d-%d=%d=%d\n FL, Xad.Overflow, Xad.Icnt, Xad.Rcnt, Xad.Icnt-Xad.Rcnt, BUF_NB); } wake_up_interruptible(Xad.wait); return IRQ_HANDLED; } What is Xad. ? (btw, coding style FAIL !) Are you trying to write to HW registers using a structure like that without using the appropriate MMIO register accessors ? In that case, your accesses may happen our of order since you don't have memory barriers (among other potential problems). The crash looks like you aren't properly clearing the interrupt condition on the HW, it remains asserted, tho it shouldn't overflow like that, something seems wrong with your PIC. What HW is this ? What PIC ? It looks like the interrupt source isn't masked on the PIC itself while it's being handled or something... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc endian issue
Hello, I am using perf to collect data from powerpc and analyze the data on a local server. When I am trying to use perf report the error fatal:imcompatible file format comes up. It is noticed that the error is generated due to perf_header size dismatch. The issue is caused by that the powerpc is big endian and local server is little endian. I am wondering if any of you have ideas how to solve this problem. Basically, how to analyze the perf.data generated on a powerpc on a little endian Machine. Sincerely yours, Yuan ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: {PATCH] Firmware update using the update_flash -f filename results to soft lockup BUG
In message 4e155f15.1030...@linux.vnet.ibm.com you wrote: This is a multi-part message in MIME format. --===3790206687486290502== Content-Type: multipart/alternative; boundary=080309090408040507080807 This is a multi-part message in MIME format. --080309090408040507080807 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On Thursday 07 July 2011 11:42 AM, Michael Neuling wrote: In message4e1543b6.9060...@linux.vnet.ibm.com you wrote: Hi , Problem Description: Firmware update using the update_flash -ffilename results to soft lock up BUG FLASH: preparing saved firmware image for flash FLASH: flash image is 50141296 bytes FLASH: performing flash and reboot FLASH: this will take several minutes. Do not power off! BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36] Steps to reproduce: 1. Check the firmware information on the machine (using ASM or lsmcode) 2. Update the system firmware with the update_flash command update_flash -f 01FL350_039_038.img info: Temporary side will be updated with a newer or identical image Projected Flash Update Results: Current T Image: FL350_039 Current P Image: FL350_039 New T Image: FL350_039 New P Image: FL350_039 Flash image ready...rebooting the system... Broadcast message from root@abc (/dev/hvc0) at 5:25 ... The system is going down for reboot NOW! [root@abc /]# Stopping rhsmcertd[ OK ] Stopping atd: [ OK ] Stopping cups: [ OK ] Stopping abrt daemon: [ OK ] Stopping sshd: [ OK ] Shutting down postfix: [ OK ] Stopping rtas_errd (platform error handling) daemon: [ OK ] Stopping crond: [ OK ] Stopping automount: [ OK ] Stopping HAL daemon: [ OK ] Stopping iprdump: [ OK ] Killing mdmonitor: [ OK ]] Stopping system message bus: [ OK ] Stopping rpcbind: [ OK ] Stopping auditd: [ OK ] Shutting down interface eth0: [ OK ] Shutting down loopback interface: [ OK ] ip6tables: Flushing firewall rules: [ OK ] ip6tables: Setting chains to policy ACCEPT: filter [ OK ] ip6tables: Unloading modules: [ OK ] iptables: Flushing firewall rules: [ OK ] iptables: Setting chains to policy ACCEPT: filter [ OK ] iptables: Unloading modules: [ OK ] Sending all processes the TERM signal... [ OK ] Sending all processes the KILL signal... [ OK ] Saving random seed: [ OK ] Turning off swap: [ OK ] Turning off quotas: [ OK ] Unmounting pipe file systems: [ OK ] Unmounting file systems: [ OK ] init: Re-executing /sbin/init Please stand by while rebooting the system... Restarting system. FLASH: preparing saved firmware image for flash FLASH: flash image is 50141296 bytes FLASH: performing flash and reboot FLASH: this will take several minutes. Do not power off! BUG: soft lockup - CPU#1 stuck for 67s! [events/1:36] This is solved by the following patch Can you please explain how it fixes it? The flash update is conducted with an RTAS call. The RTAS calls are serialized by lock_rtas() which uses a spin_lock. Now there is rtasd which keeps scanning for the RTAS events generated on the machine. This is performed via workqueue mechanism. The rtas_event_scan() also uses an RTAS call to scan the events, eventually taking the lock_rtas() before it issues the request. The flash update is an operation which takes long time, and hence while we are at it, anyboy else who wants to make an RTAS call will have to wait until the update is completed. Now in this case, the rtas_event_scan() is being kicked in to check for events and it waits a long time on the spin_lock, getting us a SOFT Lockup. What other RTAS calls are going on at this point? It worries me we are stopping a CPU that's doing RTAS calls. Your solution would seem to be papering over a more serious problem. Before the rtas firmware update starts, all other CPUs should be stopped. Which means no other CPU should be in lock_rtas(). We do not want other CPUs execute while FW update is in progress and the system will be rebooted anyway after the update. Mikey ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata
On some architectures we need to setup pdev_archdata before we add the device. Waiting til a bus_notifier is too late since we might need the pdev_archdata in the bus notifier. One example is setting up of dma_mask pointers such that it can be used in a bus_notifier. We add weak noop version of arch_setup_pdev_archdata() and allow the arch code to override with access the full definitions of struct device, struct platform_device, and struct pdev_archdata. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- v4: * Move to use a weak function based on comments from Greg v3: * Add more comments and add missing call to arch_setup_pdev_archdata in platform_device_register v2: * Added license, and comments about arch_setup_pdev_archdata() per Mike's comments drivers/base/platform.c | 22 ++ include/linux/platform_device.h |1 + 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 1c291af..060686d 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -32,6 +32,26 @@ struct device platform_bus = { EXPORT_SYMBOL_GPL(platform_bus); /** + * arch_setup_pdev_archdata - Allow manipulation of archdata before its used + * @dev: platform device + * + * This is called before platform_device_add() such that any pdev_archdata may + * be setup before the platform_notifier is called. So if a user needs to + * manipulate any relevant information in the pdev_archdata they can do: + * + * platform_devic_alloc() + * ... manipulate ... + * platform_device_add() + * + * And if they don't care they can just call platform_device_register() and + * everything will just work out. + */ +void __weak arch_setup_pdev_archdata(struct platform_device *pdev) +{ + return ; +} + +/** * platform_get_resource - get a resource for a device * @dev: platform device * @type: resource type @@ -173,6 +193,7 @@ struct platform_device *platform_device_alloc(const char *name, int id) pa-pdev.id = id; device_initialize(pa-pdev.dev); pa-pdev.dev.release = platform_device_release; + arch_setup_pdev_archdata(pa-pdev); } return pa ? pa-pdev : NULL; @@ -334,6 +355,7 @@ EXPORT_SYMBOL_GPL(platform_device_del); int platform_device_register(struct platform_device *pdev) { device_initialize(pdev-dev); + arch_setup_pdev_archdata(pdev); return platform_device_add(pdev); } EXPORT_SYMBOL_GPL(platform_device_register); diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h index ede1a80..27bb05a 100644 --- a/include/linux/platform_device.h +++ b/include/linux/platform_device.h @@ -42,6 +42,7 @@ extern void platform_device_unregister(struct platform_device *); extern struct bus_type platform_bus_type; extern struct device platform_bus; +extern void arch_setup_pdev_archdata(struct platform_device *); extern struct resource *platform_get_resource(struct platform_device *, unsigned int, unsigned int); extern int platform_get_irq(struct platform_device *, unsigned int); extern struct resource *platform_get_resource_byname(struct platform_device *, unsigned int, const char *); -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 2/3] powerpc: implement arch_setup_pdev_archdata
We have a long standing issues with platform devices not have a valid dma_mask pointer. This hasn't been an issue to date as no platform device has tried to set its dma_mask value to a non-default value. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/kernel/setup-common.c | 28 drivers/of/platform.c |4 ++-- 2 files changed, 6 insertions(+), 26 deletions(-) diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c index 79fca26..ea82baa 100644 --- a/arch/powerpc/kernel/setup-common.c +++ b/arch/powerpc/kernel/setup-common.c @@ -704,29 +704,9 @@ static int powerpc_debugfs_init(void) arch_initcall(powerpc_debugfs_init); #endif -static int ppc_dflt_bus_notify(struct notifier_block *nb, - unsigned long action, void *data) +void arch_setup_pdev_archdata(struct platform_device *pdev) { - struct device *dev = data; - - /* We are only intereted in device addition */ - if (action != BUS_NOTIFY_ADD_DEVICE) - return 0; - - set_dma_ops(dev, dma_direct_ops); - - return NOTIFY_DONE; -} - -static struct notifier_block ppc_dflt_plat_bus_notifier = { - .notifier_call = ppc_dflt_bus_notify, - .priority = INT_MAX, -}; - -static int __init setup_bus_notifier(void) -{ - bus_register_notifier(platform_bus_type, ppc_dflt_plat_bus_notifier); - return 0; + pdev-archdata.dma_mask = DMA_BIT_MASK(32); + pdev-dev.dma_mask = pdev-archdata.dma_mask; + set_dma_ops(pdev-dev, dma_direct_ops); } - -arch_initcall(setup_bus_notifier); diff --git a/drivers/of/platform.c b/drivers/of/platform.c index 63d3cb7..cfc6a79 100644 --- a/drivers/of/platform.c +++ b/drivers/of/platform.c @@ -153,7 +153,7 @@ struct platform_device *of_device_alloc(struct device_node *np, } dev-dev.of_node = of_node_get(np); -#if defined(CONFIG_PPC) || defined(CONFIG_MICROBLAZE) +#if defined(CONFIG_MICROBLAZE) dev-dev.dma_mask = dev-archdata.dma_mask; #endif dev-dev.parent = parent; @@ -189,7 +189,7 @@ struct platform_device *of_platform_device_create(struct device_node *np, if (!dev) return NULL; -#if defined(CONFIG_PPC) || defined(CONFIG_MICROBLAZE) +#if defined(CONFIG_MICROBLAZE) dev-archdata.dma_mask = 0xUL; #endif dev-dev.coherent_dma_mask = DMA_BIT_MASK(32); -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 3/3] powerpc: Dont require a dma_ops struct to set dma mask
The only reason to require a dma_ops struct is to see if it has implemented set_dma_mask. If not we can fall back to setting the mask directly. This resolves an issue with how to sequence the setting of a DMA mask for platform devices. Before we had an issue in that we have no way of setting the DMA mask before the various low level bus notifiers get called that might check it (swiotlb). So now we can do: pdev = platform_device_alloc(foobar, 0); dma_set_mask(pdev-dev, DMA_BIT_MASK(37)); platform_device_add(pdev); And expect the right thing to happen with the bus notifiers get called via platform_device_add. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- arch/powerpc/kernel/dma.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/powerpc/kernel/dma.c b/arch/powerpc/kernel/dma.c index d238c08..4f0959f 100644 --- a/arch/powerpc/kernel/dma.c +++ b/arch/powerpc/kernel/dma.c @@ -161,9 +161,7 @@ int dma_set_mask(struct device *dev, u64 dma_mask) if (ppc_md.dma_set_mask) return ppc_md.dma_set_mask(dev, dma_mask); - if (unlikely(dma_ops == NULL)) - return -EIO; - if (dma_ops-set_dma_mask != NULL) + if ((dma_ops != NULL) (dma_ops-set_dma_mask != NULL)) return dma_ops-set_dma_mask(dev, dma_mask); if (!dev-dma_mask || !dma_supported(dev, dma_mask)) return -EIO; -- 1.7.3.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3 1/3] driver core: Add ability for arch code to setup pdev_archdata
On Jul 7, 2011, at 9:11 AM, Greg KH wrote: On Thu, Jul 07, 2011 at 08:55:44AM -0500, Kumar Gala wrote: On Jul 1, 2011, at 5:09 PM, Greg KH wrote: On Thu, Jun 23, 2011 at 06:33:57AM -0500, Kumar Gala wrote: On some architectures we need to setup pdev_archdata before we add the device. Waiting til a bus_notifier is too late since we might need the pdev_archdata in the bus notifier. One example is setting up of dma_mask pointers such that it can be used in a bus_notifier. We add noop version of arch_setup_pdev_archdata() in asm-generic/platform_device.h and allow the arch code to override with access the full definitions of struct device, struct platform_device, and struct pdev_archdata. Isn't there some way to use weak symbols to keep us from having to create this .h file in every single arch and then if the arch wants to define it, it does so? That should make this patch simpler, right? thanks, greg k-h Changing to weak should be doable if we are ok with the additional function call always happening. Given that this is not a fast path, and the function call for the normal case would do nothing, it should be fine, right? greg k-h Sounds good, new version sent that uses weak instead. If this looks good let me know if you just want to ACK and send via powerpc.git tree or if you'll pick these up. - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] Remove a BUG_ON that triggered when running under FSL Hypervisor
On Jul 7, 2011, at 8:44 AM, Laurentiu TUDOR wrote: mpc85xx_smp_init platform init function assumed that smp_ops.message_pass was set to default arch dependent smp_muxed_ipi_message_pass. However this does not seem to happen. Moreover, the arch specific code in arch/powerpc/kernel/smp.c handles smp_ops.message_pass == NULL and if so calls the default implementation. Signed-off-by: Laurentiu TUDOR laurentiu.tu...@freescale.com --- arch/powerpc/platforms/85xx/smp.c |9 + 1 files changed, 5 insertions(+), 4 deletions(-) Re-worded commit message a bit, applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/p1022ds: Remove fixed-link property from ethernet nodes.
On Jul 7, 2011, at 2:37 AM, Felix Radensky wrote: On P1022DS both ethernet controllers are connected to RGMII PHYs accessible via MDIO bus. Remove fixed-link property from ethernet nodes as they only required when fixed link PHYs without MDIO bus are used. Signed-off-by: Felix Radensky fe...@embedded-sol.com --- arch/powerpc/boot/dts/p1022ds.dts |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) applied to next ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc/85xx: Add p2040 RDB board support
On Jun 28, 2011, at 2:52 AM, Mingkai Hu wrote: P2040RDB Specification: --- 2Gbyte unbuffered DDR3 SDRAM SO-DIMM(64bit bus) 128 Mbyte NOR flash single-chip memory 256 Kbit M24256 I2C EEPROM 16 Mbyte SPI memory SD connector to interface with the SD memory card dTSEC1: connected to the Vitesse SGMII PHY (VSC8221) dTSEC2: connected to the Vitesse SGMII PHY (VSC8221) dTSEC3: connected to the Vitesse SGMII PHY (VSC8221) dTSEC4: connected to the Vitesse RGMII PHY (VSC8641) dTSEC5: connected to the Vitesse RGMII PHY (VSC8641) I2C1: Real time clock, Temperature sensor I2C2: Vcore Regulator, 256Kbit I2C Bus EEPROM SATA: Lanes C and Land D of Bank2 are connected to two SATA connectors UART: supports two UARTs up to 115200 bps for console USB 2.0: connected via a internal UTMI PHY to two TYPE-A interfaces PCIe: - Lanes E, F, G and H of Bank1 are connected to one x4 PCIe SLOT1 - Lanes C and Land D of Bank2 are connected to one x4 PCIe SLOT2 Signed-off-by: Mingkai Hu mingkai...@freescale.com --- Based on http://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git arch/powerpc/boot/dts/p2040rdb.dts | 166 +++ arch/powerpc/boot/dts/p2040si.dtsi | 623 ++ arch/powerpc/configs/corenet32_smp_defconfig |1 + arch/powerpc/platforms/85xx/Kconfig | 12 + arch/powerpc/platforms/85xx/Makefile |1 + arch/powerpc/platforms/85xx/p2040_rdb.c | 88 6 files changed, 891 insertions(+), 0 deletions(-) create mode 100644 arch/powerpc/boot/dts/p2040rdb.dts create mode 100644 arch/powerpc/boot/dts/p2040si.dtsi create mode 100644 arch/powerpc/platforms/85xx/p2040_rdb.c applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH 4/5] powerpc: Create next_tlbcam_idx percpu variable for FSL_BOOKE
On Jun 28, 2011, at 2:54 PM, Becky Bruce wrote: From: Becky Bruce bec...@kernel.crashing.org This is used to round-robin TLBCAM entries. Signed-off-by: Becky Bruce bec...@kernel.crashing.org --- arch/powerpc/include/asm/mmu.h |5 + arch/powerpc/kernel/smp.c |4 arch/powerpc/mm/mem.c |9 + arch/powerpc/mm/tlb_nohash.c |6 ++ 4 files changed, 24 insertions(+), 0 deletions(-) applied to next - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata
On Thu, Jul 07, 2011 at 11:00:41PM -0500, Kumar Gala wrote: On some architectures we need to setup pdev_archdata before we add the device. Waiting til a bus_notifier is too late since we might need the pdev_archdata in the bus notifier. One example is setting up of dma_mask pointers such that it can be used in a bus_notifier. We add weak noop version of arch_setup_pdev_archdata() and allow the arch code to override with access the full definitions of struct device, struct platform_device, and struct pdev_archdata. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- v4: * Move to use a weak function based on comments from Greg v3: * Add more comments and add missing call to arch_setup_pdev_archdata in platform_device_register v2: * Added license, and comments about arch_setup_pdev_archdata() per Mike's comments drivers/base/platform.c | 22 ++ include/linux/platform_device.h |1 + 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 1c291af..060686d 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -32,6 +32,26 @@ struct device platform_bus = { EXPORT_SYMBOL_GPL(platform_bus); /** + * arch_setup_pdev_archdata - Allow manipulation of archdata before its used + * @dev: platform device + * + * This is called before platform_device_add() such that any pdev_archdata may + * be setup before the platform_notifier is called. So if a user needs to + * manipulate any relevant information in the pdev_archdata they can do: + * + * platform_devic_alloc() + * ... manipulate ... + * platform_device_add() + * + * And if they don't care they can just call platform_device_register() and + * everything will just work out. + */ +void __weak arch_setup_pdev_archdata(struct platform_device *pdev) +{ + return ; +} The return isn't needed, nor is the extra ' ' there, right? :) Change that and you can take this through the ppc tree and add a: Acked-by: Greg Kroah-Hartman to them. thanks, greg k-h ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 1/3] driver core: Add ability for arch code to setup pdev_archdata
On Jul 7, 2011, at 11:22 PM, Greg KH wrote: On Thu, Jul 07, 2011 at 11:00:41PM -0500, Kumar Gala wrote: On some architectures we need to setup pdev_archdata before we add the device. Waiting til a bus_notifier is too late since we might need the pdev_archdata in the bus notifier. One example is setting up of dma_mask pointers such that it can be used in a bus_notifier. We add weak noop version of arch_setup_pdev_archdata() and allow the arch code to override with access the full definitions of struct device, struct platform_device, and struct pdev_archdata. Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- v4: * Move to use a weak function based on comments from Greg v3: * Add more comments and add missing call to arch_setup_pdev_archdata in platform_device_register v2: * Added license, and comments about arch_setup_pdev_archdata() per Mike's comments drivers/base/platform.c | 22 ++ include/linux/platform_device.h |1 + 2 files changed, 23 insertions(+), 0 deletions(-) diff --git a/drivers/base/platform.c b/drivers/base/platform.c index 1c291af..060686d 100644 --- a/drivers/base/platform.c +++ b/drivers/base/platform.c @@ -32,6 +32,26 @@ struct device platform_bus = { EXPORT_SYMBOL_GPL(platform_bus); /** + * arch_setup_pdev_archdata - Allow manipulation of archdata before its used + * @dev: platform device + * + * This is called before platform_device_add() such that any pdev_archdata may + * be setup before the platform_notifier is called. So if a user needs to + * manipulate any relevant information in the pdev_archdata they can do: + * + * platform_devic_alloc() + * ... manipulate ... + * platform_device_add() + * + * And if they don't care they can just call platform_device_register() and + * everything will just work out. + */ +void __weak arch_setup_pdev_archdata(struct platform_device *pdev) +{ +return ; +} The return isn't needed, nor is the extra ' ' there, right? :) yep, removed the ';' as well ;) Change that and you can take this through the ppc tree and add a: Acked-by: Greg Kroah-Hartman to them. Ack added to all. thanks - k ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev