Re: [PATCH 1/9 v2] powerpc: change FDT compatible prefix to mrvl
Either use the stock ticker, in UPPER CASE, or use a nice descriptive name. The lower case space is free for all, using shortened names (like mrvl) there only increases the chances of collisions. Frankly Segher, it doesn't matter to me. However, NONE of the existing DTS files use upper-case stock ticker. I see no reason to deviate from the existing convention It's not an existing convention, it's a mistake some people made ;-) (even if that convention doesn't follow the previously defined upper-case stock ticker convention.) That's not a previously defined convention, it's the defined rules in the OF standard. Conventions are examples that are nice to follow if there's no real reason to choose either way; standards are things that if you break them, people shout out you. Let me say this again: it is *fine* if you use some lower-case name. In that case though, marvell is slightly better than mrvl, and you had the former already, so just keep it :-) Agreed? Ca we move on now? :-) Segher ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
Kamalesh Babulal writes: The Kernel oopses is seen while running the kernbench followed by tbench with 2.6.25-rc2-git4 kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel (http://lkml.org/lkml/2008/1/18/71) and is visible with almost all of the main line ,rc(s) and their git(s) release from then. This oops is visible in the linux-next-20080220 kernel also.The machine is power4+ box with four cpus and has 30 GB RAM. Please try to replicate the oops with the patch below applied. It doesn't solve the cause of the oops but it should mean the kernel prints out more useful information about the cause of the oops. I assume you can replicate the oops easily on this machine - is that right? Paul. diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 11b4f6d..a3ac72a 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -621,7 +621,7 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES) mtlrr10 andi. r10,r12,MSR_RI /* check for unrecoverable exception */ - beq-unrecov_slb + beq-2f .machine push .machine power4 @@ -643,6 +643,22 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES) rfid b . /* prevent speculative execution */ +2: +#ifdef CONFIG_PPC_ISERIES +BEGIN_FW_FTR_SECTION + b unrecov_slb +END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES) +#endif /* CONFIG_PPC_ISERIES */ + mfspr r11,SPRN_SRR0 + clrrdi r10,r13,32 + LOAD_HANDLER(r10,unrecov_slb) + mtspr SPRN_SRR0,r10 + mfmsr r10 + ori r10,r10,MSR_IR|MSR_DR|MSR_RI + mtspr SPRN_SRR1,r10 + rfid + b . + unrecov_slb: EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB) DISABLE_INTS ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - unable to handle paging request @ 0
Scott Wood schrieb: On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote: Kernel starts and crashes with unable to handle kernel paging request @ . After turning debug on in some files I can see that the initrd memory gets reserved and the dtb is parsed correctly. PCI memory/io spaces are set up fine. At first I thought this is a problem with the device tree since the call trace always points to of_-functions and strcmp. Could you provide this call trace? -Scott Scott, thanks for your reply. please find below the output after the bootm command in u-boot. My System.map : ... c00126b8 T strcpy c00126d4 T strncpy c0012714 T strcat c0012740 T strcmp c0012764 T strlen c001277c T memcmp ... c0140bc4 T of_find_property c0140c74 T of_get_property c0140ca8 T of_device_is_compatible c0140d48 T of_match_node c0140e68 T of_find_matching_node c0140f20 T of_n_size_cells c0140f9c T of_n_addr_cells Log: # Booting kernel from Legacy Image at ff81 ... Image Name: 2.6.25 mvBL-M7 MPC8343 #1 Image Type: PowerPC Linux Kernel Image (uncompressed) Data Size:2084636 Bytes = 2 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Kernel Image ... OK OK ## Flattened Device Tree blob at Booting using the fdt blob at 0x60 ## Loading init Ramdisk from Legacy Image at 0100 ... Image Name: mvBC-1G uInitrd #1.1.03 Image Type: PowerPC Linux RAMDisk Image (uncompressed) Data Size:2654208 Bytes = 2.5 MB Load Address: Entry Point: Verifying Checksum ... OK Loading Ramdisk to 1fcb7000, end 1ff3f000 ... OK - early_init_devtree(c060) search chosen, depth: 0, uname: search chosen, depth: 1, uname: chosen Looking for initrd properties... 3initrd_start=0xdfcb7000 initrd_end=0xdff3f000 Command line is: root=/dev/ram ro rootfstype=squashfs dt_root_size_cells = 1 dt_root_addr_cells = 1 memory scan node memory, reg size 8, data: 0 2000 2 1, - 0 , 2000 reserving: 1fcb7000 - 288001 Phys. mem: 2000 - move_device_tree - move_device_tree Scanning CPUs ... boot cpu: logical 0 physical 0 - early_init_devtree() Using mvBlueLYNX-M7 machine description Linux version 2.6.25-rc8-01197-g1de15bb-dirty ([EMAIL PROTECTED]) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #1 PREEMPT Tue Apr 8 10:40:51 CEST 2008 - unflatten_device_tree() size is 1840, allocating... unflattening dfffe7bc... fixed up name for - fixed up name for chosen - chosen fixed up name for aliases - aliases fixed up name for cpus - cpus fixed up name for PowerPC,[EMAIL PROTECTED] - PowerPC,8343 fixed up name for memory - memory fixed up name for [EMAIL PROTECTED] - soc8343 fixed up name for [EMAIL PROTECTED] - wdt fixed up name for [EMAIL PROTECTED] - i2c fixed up name for [EMAIL PROTECTED] - rtc fixed up name for [EMAIL PROTECTED] - i2c fixed up name for [EMAIL PROTECTED] - spi fixed up name for [EMAIL PROTECTED] - usb fixed up name for [EMAIL PROTECTED] - mdio fixed up name for [EMAIL PROTECTED] - ethernet-phy fixed up name for [EMAIL PROTECTED] - ethernet-phy fixed up name for [EMAIL PROTECTED] - ethernet fixed up name for [EMAIL PROTECTED] - ethernet fixed up name for [EMAIL PROTECTED] - serial fixed up name for [EMAIL PROTECTED] - serial fixed up name for [EMAIL PROTECTED] - pic fixed up name for [EMAIL PROTECTED] - localbus fixed up name for [EMAIL PROTECTED],0 - flash - unflatten_device_tree() Found initrd at 0xdfcb7000:0xdff3f000 console [udbg0] enabled setup_arch: bootmem mvblm7_setup_arch() Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0012748 Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT mvBlueLYNX-M7 Modules linked in: NIP: c0012748 LR: c0140c10 CTR: REGS: c01f9e40 TRAP: 0300 Not tainted (2.6.25-rc8-01197-g1de15bb-dirty) MSR: 1032 ME,IR,DR CR: 22008048 XER: 2000 DAR: , DSISR: 2000 TASK = c01e4510[0] 'swapper' THREAD: c01f8000 GPR00: c0140c84 c01f9ef0 c01e4510 c0197a7f c01f9edc GPR08: c01f15e4 0003 c0600b84 004d 22002048 ffdf 1fffd000 GPR16: ffdf 7fdf 1fff8974 1ff426f8 0004 00288000 GPR24: 0002 5f0f c01993e4 c01f9f28 c0197a80 c01f8000 d9e4 Call Trace: [c01f9ef0] [c001c190] (unreliable) [c01f9f10] [c0140c84] [c01f9f20] [c0140ccc] [c01f9f40] [c014145c] [c01f9f60] [c0014014] [c01f9fa0] [c01d1a40] [c01f9fb0] [c01ce64c] [c01f9fc0] [c01c55ac] [c01f9ff0] [3438] Instruction dump: 3884 8c050001 2c00 4082fff8 38a5 8c040001 2c00 9c050001 4082fff4 4e800020 38a3 3884 8c650001 2c83 8c040001 7c601851 ---[ end trace 8640abe69a316dee ]--- Kernel panic - not syncing: Attempted to kill the idle task! Rebooting in 180 seconds.. Please let me know if you need more information. regards, Andre MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts.
There are several limitations in this support:
1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
This is straightforward to implement when needed, two timers should
be marked as requested and configured as appropriate.
2. Super-cascaded (64 bit) timers unimplemented (1-2-3-4).
This is also straightforward to implement when needed, all timers
should be marked as requested and configured as appropriate.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
[snip]
+void gtm_stop_timer_16(struct gtm_timer *tmr)
+{
+ struct gtm *gtm = tmr-gtm;
+ int num = tmr - gtm-timers[0];
+ unsigned long flags;
+
+ spin_lock_irqsave(gtm-lock, flags);
+
+ setbits8(tmr-gtcfr, GTCFR_STP(num));
Shouldn't we clear the timer events with
out_be16(tmr-gtevr, 0x);
here ? Otherwise the timer interrupt could still fire after the timer is
stopped. This introduces a race condition in drivers that blindly re-arm the
timer in the interrupt handler. I've been bitten by this while porting your
FHCI USB driver to a CPM2 platform.
+
+ spin_unlock_irqrestore(gtm-lock, flags);
+}
+EXPORT_SYMBOL(gtm_stop_timer_16);
--
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
pgpCeicGrAIHJ.pgp
Description: PGP signature
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Booting a Xilinx board
Are you using uartlite? Try console=ttyUL0. Thanks, I didn't know that. But Stephen is right, the first thing you should do is look at __log_buf. You can find its address in the System.map file. Unfortunately, the installation of the cable driver failed for some reason. I'll have to work on it... -- Guillaume Dargaud http://www.gdargaud.net/Antarctica/ ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[Fwd: Re: MPC8343 - unable to handle paging request @ 0]
sorry - forgot Kim + List Original-Nachricht Betreff:Re: MPC8343 - unable to handle paging request @ 0 Datum: Tue, 08 Apr 2008 13:29:20 +0200 Von:Andre Schwarz [EMAIL PROTECTED] An: Scott Wood [EMAIL PROTECTED] Referenzen: [EMAIL PROTECTED] [EMAIL PROTECTED] Scott Wood schrieb: On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote: Kernel starts and crashes with unable to handle kernel paging request @ . After turning debug on in some files I can see that the initrd memory gets reserved and the dtb is parsed correctly. PCI memory/io spaces are set up fine. At first I thought this is a problem with the device tree since the call trace always points to of_-functions and strcmp. Could you provide this call trace? -Scott Scott, after removing mpc834x_usb_cfg() from my mvblm7_setup_arch() the crash is delayed ... regards, Andre System-map : c0012098 T strcpy c00120b4 T strncpy c00120f4 T strcat c0012120 T strcmp c0012144 T strlen ... c00ecd08 T of_find_property c00ecda4 T of_get_property c00ecdd8 T of_n_size_cells console [udbg0] enabled setup_arch: bootmem mvblm7_setup_arch() arch: exit Zone PFN ranges: DMA 0 - 131072 Normal 131072 - 131072 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0:0 - 131072 Built 1 zonelists in Zone order, mobility grouping on. Total pages: 130048 Kernel command line: root=/dev/ram ro rootfstype=squashfs PID hash table entries: 2048 (order: 11, 8192 bytes) clocksource: timebase mult[3c1] shift[22] registered Unable to handle kernel paging request for data at address 0x Faulting instruction address: 0xc0012128 Oops: Kernel access of bad area, sig: 11 [#1] mvBlueLYNX-M7 Modules linked in: NIP: c0012128 LR: c00ecd44 CTR: 0007 REGS: c0193ec0 TRAP: 0300 Not tainted (2.6.25-rc8-01197-g1de15bb-dirty) MSR: 9032 EE,ME,IR,DR CR: 48002048 XER: DAR: , DSISR: 2000 TASK = c0182510[0] 'swapper' THREAD: c0192000 GPR00: c00ecdb4 c0193f70 c0182510 c01401c7 c017a808 c00db350 GPR08: c018 000a2c20 c017d3f4 4842 dfd7 1fffd000 GPR16: dfd7 dfd7 1fff8974 1ff426f8 0004 00288000 GPR24: c0198fa0 c019 c019 c01401c8 dfa8 Call Trace: [c0193f70] [] (unreliable) [c0193f90] [c00ecdb4] [c0193fa0] [c016df50] [c0193fb0] [c017705c] [c0193fc0] [c01646b4] [c0193ff0] [3438] Instruction dump: 3884 8c050001 2c00 4082fff8 38a5 8c040001 2c00 9c050001 4082fff4 4e800020 38a3 3884 8c650001 2c83 8c040001 7c601851 ---[ end trace 8640abe69a316dee ]--- Kernel panic - not syncing: Attempted to kill the idle task! Rebooting in 180 seconds.. MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/8] [POWERPC] sysdev,qe_lib: implement FSL GTM support
On Tue, Apr 08, 2008 at 11:01:53AM +0200, Laurent Pinchart wrote:
On Tuesday 11 March 2008 18:24, Anton Vorontsov wrote:
GTM stands for General-purpose Timers Module and able to generate
timer{1,2,3,4} interrupts.
There are several limitations in this support:
1. Cascaded (32 bit) timers unimplemented (1-2, 3-4).
This is straightforward to implement when needed, two timers should
be marked as requested and configured as appropriate.
2. Super-cascaded (64 bit) timers unimplemented (1-2-3-4).
This is also straightforward to implement when needed, all timers
should be marked as requested and configured as appropriate.
Signed-off-by: Anton Vorontsov [EMAIL PROTECTED]
[snip]
+void gtm_stop_timer_16(struct gtm_timer *tmr)
+{
+ struct gtm *gtm = tmr-gtm;
+ int num = tmr - gtm-timers[0];
+ unsigned long flags;
+
+ spin_lock_irqsave(gtm-lock, flags);
+
+ setbits8(tmr-gtcfr, GTCFR_STP(num));
Shouldn't we clear the timer events with
out_be16(tmr-gtevr, 0x);
Yeah.
here ? Otherwise the timer interrupt could still fire after the timer is
stopped. This introduces a race condition in drivers that blindly re-arm the
timer in the interrupt handler. I've been bitten by this while porting your
FHCI USB driver to a CPM2 platform.
Thanks, will fix.
--
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: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
Paul Mackerras wrote: Kamalesh Babulal writes: The Kernel oopses is seen while running the kernbench followed by tbench with 2.6.25-rc2-git4 kernel on powerpc, this oops was reported for the 2.6.24-rc8-mm1 kernel (http://lkml.org/lkml/2008/1/18/71) and is visible with almost all of the main line ,rc(s) and their git(s) release from then. This oops is visible in the linux-next-20080220 kernel also.The machine is power4+ box with four cpus and has 30 GB RAM. Please try to replicate the oops with the patch below applied. It doesn't solve the cause of the oops but it should mean the kernel prints out more useful information about the cause of the oops. I assume you can replicate the oops easily on this machine - is that right? Paul. diff --git a/arch/powerpc/kernel/head_64.S b/arch/powerpc/kernel/head_64.S index 11b4f6d..a3ac72a 100644 --- a/arch/powerpc/kernel/head_64.S +++ b/arch/powerpc/kernel/head_64.S @@ -621,7 +621,7 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES) mtlrr10 andi. r10,r12,MSR_RI /* check for unrecoverable exception */ - beq-unrecov_slb + beq-2f .machine push .machine power4 @@ -643,6 +643,22 @@ END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES) rfid b . /* prevent speculative execution */ +2: +#ifdef CONFIG_PPC_ISERIES +BEGIN_FW_FTR_SECTION + b unrecov_slb +END_FW_FTR_SECTION_IFSET(FW_FEATURE_ISERIES) +#endif /* CONFIG_PPC_ISERIES */ + mfspr r11,SPRN_SRR0 + clrrdi r10,r13,32 + LOAD_HANDLER(r10,unrecov_slb) + mtspr SPRN_SRR0,r10 + mfmsr r10 + ori r10,r10,MSR_IR|MSR_DR|MSR_RI + mtspr SPRN_SRR1,r10 + rfid + b . + unrecov_slb: EXCEPTION_PROLOG_COMMON(0x4100, PACA_EXSLB) DISABLE_INTS Hi Paul, The kernel oops after applying the patch. Some time it takes more than one run to reproduce it, it was reproducible in the second run this time. Unrecoverable exception 4100 at c0008c8c Oops: Unrecoverable exception, sig: 6 [#1] SMP NR_CPUS=128 NUMA pSeries Modules linked in: NIP: c0008c8c LR: 0ff0135c CTR: 0ff012f0 REGS: c00772343bb0 TRAP: 4100 Not tainted (2.6.25-rc8-autotest) MSR: 80001030 ME,IR,DR CR: 44044228 XER: TASK = c0077cfa0900[13437] 'cc1' THREAD: c0077234 CPU: 2 GPR00: 4000 c00772343e30 00bb d032 GPR04: 00bb 0400 000a 0002 GPR08: GPR12: c0734000 0064 ffe6df08 GPR16: 105b 105b 1044 105b GPR20: ffe6e008 105b 105b 000a GPR24: 0ffec408 0001 ffe6ddca 0400 GPR28: 0ffec408 f7ff8000 0ffebff4 0400 NIP [c0008c8c] restore+0x8c/0xc0 LR [0ff0135c] 0xff0135c Call Trace: [c00772343e30] [c0008cd4] do_work+0x14/0x2c (unreliable) Instruction dump: 7c840078 7c810164 70604000 41820028 6000 7c4c42e6 e88d01f0 f84d01f0 7c841050 e84d01e8 7c422214 f84d01e8 e9a100d8 7c7b03a6 e84101a0 7c4ff120 (gdb) l *0xc0008cdc 0xc0008cdc is at arch/powerpc/kernel/entry_64.S:608. 603 mtmsrd r10,1 604 605 andi. r0,r4,_TIF_NEED_RESCHED 606 beq 1f 607 bl .schedule 608 b .ret_from_except_lite 609 610 1: bl .save_nvgprs 611 li r3,0 612 addir4,r1,STACK_FRAME_OVERHEAD please let me know if you need more information. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] Freescale QUICC Engine USB Host Controller
On Mon, Apr 07, 2008 at 06:11:15PM +0200, Laurent Pinchart wrote: [...] I had a first go at hacking the FHCI driver to make it run on a CPM2 platform. Results so far are quite good. After getting rid of qe-specific APIs as explained above, and adding SOF token generation support, I've been able to access a mass storage device. The driver hasn't been stress-tested yet though. Wow, awesome! That's great news, really. Looking forward for the patch. :-) I ran into an issue with IDLE and RESET interrupts. When the device is first plugged into the USB port, the idle interrupt kicks in and the driver detects the device properly. When the device is then removed, the reset interrupt is generated and the driver handles device removal properly. Right after the reset interrupt, idle interrupts are generated every milliseconds for around 175ms. The status register always reports a non-idle condition when read in the interrupt handler. The flow of idle interrupts then stops, and no idle interrupt is generated when I replug the device. I've checked the interrupts mask register to make sure idle interrupts were enabled. Have you noticed a similar behaviour when you tested the driver on your QE-based platform ? I suspected a debouncing issue, but I should then get idle conditions once every other time when reading the status register. Hm.. nope, I didn't see anything like that, at least not something that is affecting the driver functionality. Did out_be16(tmr-gtevr, 0x); help there? Or it's different problem? -- 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: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
Kamalesh Babulal writes: The kernel oops after applying the patch. Some time it takes more than one run to reproduce it, it was reproducible in the second run this time. Unrecoverable exception 4100 at c0008c8c Oops: Unrecoverable exception, sig: 6 [#1] SMP NR_CPUS=128 NUMA pSeries Modules linked in: NIP: c0008c8c LR: 0ff0135c CTR: 0ff012f0 REGS: c00772343bb0 TRAP: 4100 Not tainted (2.6.25-rc8-autotest) MSR: 80001030 ME,IR,DR CR: 44044228 XER: TASK = c0077cfa0900[13437] 'cc1' THREAD: c0077234 CPU: 2 GPR00: 4000 c00772343e30 00bb d032 GPR04: 00bb 0400 000a 0002 GPR08: GPR12: c0734000 0064 ffe6df08 GPR16: 105b 105b 1044 105b GPR20: ffe6e008 105b 105b 000a GPR24: 0ffec408 0001 ffe6ddca 0400 GPR28: 0ffec408 f7ff8000 0ffebff4 0400 NIP [c0008c8c] restore+0x8c/0xc0 LR [0ff0135c] 0xff0135c Call Trace: [c00772343e30] [c0008cd4] do_work+0x14/0x2c (unreliable) Instruction dump: 7c840078 7c810164 70604000 41820028 6000 7c4c42e6 e88d01f0 f84d01f0 7c841050 e84d01e8 7c422214 f84d01e8 e9a100d8 7c7b03a6 e84101a0 7c4ff120 (gdb) l *0xc0008cdc 0xc0008cdc is at arch/powerpc/kernel/entry_64.S:608. 603 mtmsrd r10,1 604 605 andi. r0,r4,_TIF_NEED_RESCHED 606 beq 1f 607 bl .schedule 608 b .ret_from_except_lite 609 610 1: bl .save_nvgprs 611 li r3,0 612 addir4,r1,STACK_FRAME_OVERHEAD The exception happened at c...8c8c but you looked at c...8cdc with gdb. What's at c...8c8c? please let me know if you need more information. The .config would be useful, but don't spam everyone on cc with it, just send it to me privately. Paul. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] siimage: fix kernel oops on PPC 44x
Bartlomiej Zolnierkiewicz wrote:
Fix kernel oops due to machine check occuring in init_chipset_siimage() on PPC
44x platforms. These 32-bit CPUs have 36-bit physical address and PCI I/O and
memory spaces are mapped beyond 4 GB; arch/ppc/ code has a fixup in ioremap()
that creates an illusion of the PCI I/O and memory resources being mapped below
4 GB, while arch/powerpc/ code got rid of this fixup with PPC 44x having instead
CONFIG_RESOURCES_64BIT=y -- this causes the resources to be truncated to 32-bit
'unsigned long' type in this driver, and so non-existant memory being ioremap'ed
and then accessed...
Thanks to Valentine Barshak for providing an initial patch and explanations.
Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED]
applied and pushed to Linus, thanks!
I guess that it would be worth to audit the rest of IDE code for
Already done. Some drivers, like sgiioc4, scc_pata, and pmac are prone to
that at least in theory. Although I doubt that they ever get used in such
environments as PPC 44x platform kernels, i.e. 32-bit kernel and PCI mapped
beyond 4 GB.
pci_resource_{start,end}() vs 'unsigned long' occurences and fix them.
There are quite a lot of those overall but they only pose danger if the
resource in question is in memory space since the I/O space always uses
'unsigned long' addresses. So, IDE core and drivers using only I/O resources
should not be prone to that kind of issue.
[ Even if they work at the moment they are just bugs waiting to happened
when we add support for some new platforms or rewrite the code... ]
WBR, Sergei
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - unable to handle paging request @ 0
Scott Wood schrieb:
On Sat, Apr 05, 2008 at 10:19:49AM +0200, André Schwarz wrote:
Kernel starts and crashes with unable to handle kernel paging request @
.
After turning debug on in some files I can see that the initrd memory
gets reserved and the dtb is parsed correctly.
PCI memory/io spaces are set up fine.
At first I thought this is a problem with the device tree since the call
trace always points to of_-functions and strcmp.
Could you provide this call trace?
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Scott,
after building a debug kernel and attaching the bdi2000 it looks like
the crash occurs during console_init() ...
Since we're using a dtb I omit the console=... argument for the
kernel. Is this correct ?
If console=/dev/ttyS0,115200N8 argument is given the serial console
stops working after console_init
On other PowerPC system I could see something like this during boot :
- find_legacy_serial_port()
stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED]
legacy_serial_console = 1
default console speed = 115340
- find_legacy_serial_port()
Should I see this message also ?
Have I misconfigured anything ?
u-boot prints the following dtb :
...
aliases {
name = aliases;
ethernet0 = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
ethernet1 = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
serial0 = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
serial1 = /[EMAIL PROTECTED]/[EMAIL PROTECTED];
pci0 = /[EMAIL PROTECTED];
};
cpus {
name = cpus;
#address-cells = 0x0001;
#size-cells = 0x;
PowerPC,[EMAIL PROTECTED] {
name = PowerPC,8343;
device_type = cpu;
reg = 0x;
d-cache-line-size = 0x0020;
i-cache-line-size = 0x0020;
d-cache-size = 0x8000;
i-cache-size = 0x8000;
timebase-frequency = 0x03f940aa;
bus-frequency = 0x0fe502a8;
clock-frequency = 0x17d783fc;
};
};
memory {
name = memory;
device_type = memory;
reg = 0x 0x2000;
};
[EMAIL PROTECTED] {
name = soc8343;
#address-cells = 0x0001;
#size-cells = 0x0001;
device_type = soc;
compatible = soc;
ranges = [00 00 00 00 e0 00 00 00 00 10 00 00];
reg = 0xe000 0x0200;
bus-frequency = 0x0fe502a8;
[EMAIL PROTECTED] {
device_type = watchdog;
compatible = mpc83xx_wdt;
reg = 0x0200 0x0100;
};
[EMAIL PROTECTED] {
name = i2c;
#address-cells = 0x0001;
#size-cells = 0x;
cell-index = 0x;
compatible = fsl-i2c;
reg = 0x3000 0x0100;
interrupts = 0x000e 0x0008;
interrupt-parent = 0x0001;
dfsrr;
};
[EMAIL PROTECTED] {
name = i2c;
#address-cells = 0x0001;
#size-cells = 0x;
cell-index = 0x0001;
compatible = fsl-i2c;
reg = 0x3100 0x0100;
interrupts = 0x000f 0x0008;
interrupt-parent = 0x0001;
dfsrr;
};
[EMAIL PROTECTED] {
name = spi;
cell-index = 0x;
compatible = fsl,spi;
reg = 0x7000 0x1000;
interrupts = 0x0010 0x0008;
interrupt-parent = 0x0001;
mode = cpu;
};
[EMAIL PROTECTED] {
name = usb;
compatible = fsl-usb2-mph;
reg = 0x00022000 0x1000;
#address-cells = 0x0001;
#size-cells = 0x;
interrupt-parent = 0x0001;
interrupts = 0x0027 0x0008;
phy_type = ulpi;
port0;
};
[EMAIL PROTECTED] {
name = mdio;
#address-cells =
Status of patches (ppc32 mm init clean and 85xx kernel reloc)
Paul, Here's my take on the current status of the patchset: [POWERPC] bootwrapper: Allow specifying of image physical offset reworked to look at PHDR (needs linker script update patch). Still open question on how best to do that (objdump, readelf, C program, suggestions) [POWERPC] Remove Kconfig option BOOT_LOAD should be acceptable. [POWERPC] Provide access to arch/powerpc include path on ppc64 should be acceptable (desired by others). [POWERPC] Remove and replace uses of PPC_MEMSTART with memstart_addr You had some questions about _stext and the PAGE_OFFSET vs KERNELBASE. Not sure if you are satisfied with the answers. [POWERPC] Introduce lowmem_end_addr to distiguish from total_lowmem No comments. Should be straight forward. [POWERPC] 85xx: Cleanup TLB initialization Only effects 85xx and I don't have issues with it :) [POWERPC] Use lowmem_end_addr to limit lmb allocations on ppc32 No comments. Straight forward patch. [POWERPC] Rename __initial_memory_limit to __initial_memory_limit_addr No comments. Straight forward patch. [POWERPC] Clean up some linker and symbol usage No comments. Straight forward patch. [POWERPC] Move phys_addr_t definition into asm/types.h I had an open question if the Kconfig for PHYS_64BIT should get set on PPC64 as well (has not effect). I reworked the asm/types.h bits to look like: +#if defined(CONFIG_PPC64) || defined(CONFIG_PHYS_64BIT) +typedef __u64 phys_addr_t; +#else +typedef __u32 phys_addr_t; +#endif [POWERPC] 85xx: Add support for relocatble kernel (and booting at non- zero Should probably get a bit more review. [POWERPC] Update linker script to properly set physical addresses You felt LOAD_OFFSET should be (CONFIG_PAGE_OFFSET - CONFIG_PHYSICAL_START). I disagreed. We need to resolve. I think we should be able to quickly resolve and get into powerpc-next all but the '85xx: Add support for relocatable kernel' and 'bootwrapper: Allow specifying of image..' patches. If we can close on the phys_addr_t and linker script patches that would be great. thanks - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote: On Mon, 2008-04-07 at 11:20 -0500, Scott Wood wrote: Another possible use is a BAT/TLB1 mapping for SoC registers (or anything else on the board which is frequently accessed), which can be reused by ioremap() to avoid wasting normal TLB entries, and to facilitate early debugging. As far as the above is concerned, I'm not too fan of fixed virtual addresses. I'd rather dynamically assign it. But we can do it. I'm in agreement with Ben here. On Freescale parts that could mean using up to 16M of virtual address space while in reality we may only need a handful of 4k pages to cover SoC registers that we are truly accessing at runtime. However I think there might be some utility to have an early ioremap mappings for debug. - k ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/13] devres: implement managed iomap interface
Sergei Shtylyov wrote: A very late comment but nevertheless... :-) Better late than never. Those functions are going to break on 32-bit platforms with extended physical address (well, that's starting with Pentiums which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44x). You should have used resource_size_t for the 'offset' parameter. As this most probably means that libata is broken on such platforms, I'm going to submit a patch... Yeah, right please go ahead. But I wonder whether any BIOS was actually crazy enough to map mmio region above 4G on 32bit machine. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on mpc52xx_common.c
On Tue, Apr 8, 2008 at 3:37 AM, Matt Sealey [EMAIL PROTECTED] wrote: I'd not thank Grant. I think the prom_init fixes are bordering on disgusting.. it would make it's way into commercial code for sure, but only because nobody would see what a hideous mess it is :) The best solution by far is to release a new firmware with the device tree fixed. The script method is just not tolerated by users, and patching the Linux kernel to keep track with broken firmwares is exactly what we hoped to AVOID with Aura in the first place. It may be ideal, but I don't think it is realistic. I'm now of the firm opinion that device trees and firmware are *never* perfect. Especially when the definition of perfect is a moving target. There are certainly a number of things that are wrong and missing in the Efika device tree, but in the long run it is proof that the design of OF and the device tree is good. The tree is unique. Linux and other OSes can derive the information they need. Current Linux drivers want data in a way slightly different from the way the Efika offers it; some of that is Efika's fault, some of that is the driver's fault, but OF provides the ability to massage the data and ensure the board will boot. As of right now; Linux support for the Efika contains only 4 distinct fixups: 1. Change device_type property of the / node from chrp to efika. Linux will run the wrong initialization code if this is chrp 2. change the format of the bestcomm interrupts property. The Linux drivers wants a list of interrupts and kind of treats the bestcomm engine as it's own interrupt controller. I think this was probably a design flaw on the Linux driver, but it is what we currently have. 3. the /builtin/sound node is missing an interrupts property 4. The FEC driver wants MDIO and PHY nodes to talk to the Ethernet Phy. This one is big, but it is really just a single fixup. All the other things that many not be what we *like* in the device tree are really not serious flaws. Mostly compatible properties are missing any mfg prefix like 'fsl,'. Of course, as Segher points out, 'fsl,' is better, but doesn't match recommended practice either because UPPERCASE is supposed to be used with the prefix is the stock ticker symbol. See? Device tree bindings are never perfect. :-) Regardless, the drivers deal with it and Linux is happy. Cheers, g. -- Matt Sealey [EMAIL PROTECTED] Genesi, Manager, Developer Relations Raquel and Bill wrote: Thanks Grant. RB On Mon, Apr 7, 2008 at 9:25 PM, Grant Likely [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Mon, Apr 7, 2008 at 8:14 PM, Arnd Bergmann [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: On Tuesday 08 April 2008, Matt Sealey wrote: Grant Likely wrote: Sure, why not? If the firmware has already set it up correctly and no devices using it are in use, then the kernel should be okay. :-) That said, I can't imagine choosing to not put the cdm node into the device tree. *ahem* Efika. Maybe we should just give up on making the efika boot with its regular device tree and instead add a boot wrapper that either fixes up the data provided by its firmware or just adds a proper dt blob? Current kernels boot the Efika without any firmware scripts. prom_init.c is able to handle the few fixups that the kernel really wants to see. (So life is mostly happy in Efika land now. :-) Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org mailto:Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev -- http://bbrv.blogspot.com/ -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/13] devres: implement managed iomap interface
Tejun Heo wrote: A very late comment but nevertheless... :-) Better late than never. :-) Those functions are going to break on 32-bit platforms with extended physical address (well, that's starting with Pentiums which had 36-bit PAE :-) AND devices mapped beyond 4 GB (e.g. PowerPC 44x). You should have used resource_size_t for the 'offset' parameter. As this most probably means that libata is broken on such platforms, I'm going to submit a patch... It's broken with drivers using MMIO, I meant to say. Yeah, right please go ahead. But I wonder whether any BIOS was actually crazy enough to map mmio region above 4G on 32bit machine. This is a *hardware* mapping on some non-x86 platforms (like PPC 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special hooks called from ioremap() which help create an illusion that the PCI memory space on such platforms (not only it) is mapped below 4 GB; arch/powerpc/ kernel doesn't do this anymore -- hence this newly encountered issue. WBR, Sergei ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 6/13] devres: implement managed iomap interface
Sergei Shtylyov wrote: Yeah, right please go ahead. But I wonder whether any BIOS was actually crazy enough to map mmio region above 4G on 32bit machine. This is a *hardware* mapping on some non-x86 platforms (like PPC 44x or MIPS Alchemy). The arch/ppc/ and arch/mips/ kernels have special hooks called from ioremap() which help create an illusion that the PCI memory space on such platforms (not only it) is mapped below 4 GB; arch/powerpc/ kernel doesn't do this anymore -- hence this newly encountered issue. Ah... I see. Thanks for the clarification. -- tejun ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: Add irqtrace support for 32-bit powerpc
On Mon, 2008-04-07 at 10:14 -0700, Dale Farnsworth wrote: Add the low level irq tracing hooks for 32-bit powerpc needed to enable full lockdep functionality. Dale Farnsworth [EMAIL PROTECTED] --- This version fixes the clobbering of r12 by the call to trace_hardirqs_off() that was pointed out by BenH. Johannes, I'd appreciate your trying this version if/when you get the chance. Thanks Dale, this version seems to work. I'll stress it a bit more later, but so far it has survived *much* longer than both previous versions. johannes 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: [RFC][PATCH] initial port of fixmap over from x86 for ppc32
On Tue, Apr 08, 2008 at 09:28:12AM -0500, Kumar Gala wrote: On Apr 7, 2008, at 6:51 PM, Benjamin Herrenschmidt wrote: As far as the above is concerned, I'm not too fan of fixed virtual addresses. I'd rather dynamically assign it. But we can do it. I'm in agreement with Ben here. On Freescale parts that could mean using up to 16M of virtual address space while in reality we may only need a handful of 4k pages to cover SoC registers that we are truly accessing at runtime. So make it configurable, and turn it off if you're low on address space. Most of the time, I'd think saving TLB0 entries would be more beneficial, especially with heavy I/O workloads where registers get banged on a lot. It's the early debugging that I'm really concerned with, though. It gets old hacking an early mapping in each time. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - unable to handle paging request @ 0
On Tue, Apr 08, 2008 at 10:51:18AM +0200, Andre Schwarz wrote: Call Trace: [c01f9ef0] [c001c190] (unreliable) [c01f9f10] [c0140c84] [c01f9f20] [c0140ccc] [c01f9f40] [c014145c] [c01f9f60] [c0014014] [c01f9fa0] [c01d1a40] [c01f9fb0] [c01ce64c] [c01f9fc0] [c01c55ac] [c01f9ff0] [3438] Please turn kallsyms on, which will produce an annotated call trace. Not all these addresses were in the System.map fragment. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - unable to handle paging request @ 0
On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote: after building a debug kernel and attaching the bdi2000 it looks like the crash occurs during console_init() ... Does your device tree have a /chosen node after u-boot is done with it? find_legacy_serial_ports() can crash otherwise (we really should fix that). Since we're using a dtb I omit the console=... argument for the kernel. Is this correct ? It's OK if you have /chosen/linux,stdout-path. If console=/dev/ttyS0,115200N8 argument is given the serial console stops working after console_init On other PowerPC system I could see something like this during boot : - find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] legacy_serial_console = 1 default console speed = 115340 - find_legacy_serial_port() Should I see this message also ? Only if you enable debug messages in legacy_serial.c. Have I misconfigured anything ? One thing that sticks out from the above is that you ask for ttyS0, but the stdout you list from the other system corresponds to ttyS1. Is this just a difference between the two systems? -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] [v5] Add idle wait support for 44x platforms
2 files changed, 77 insertions(+), 1 deletion(-)
arch/powerpc/platforms/44x/Makefile |2
arch/powerpc/platforms/44x/idle.c | 76 +++
Updates: Now setting MSR_WE is now default
Tested on hardware platforms bamboo sequioa and appears
things are working fine on actually hardware!
This patch adds the ability for the CPU to go into wait state while in cpu_idle
loop. This helps virtulization solutions know when the guest Linux kernel is in
an idle state. There are two ways to do it.
Command line
idle=spin -- CPU will spin
idle=wait -- set CPU into wait state when idle (default)
Signed-off-by: Jerone Young [EMAIL PROTECTED]
diff --git a/arch/powerpc/platforms/44x/Makefile
b/arch/powerpc/platforms/44x/Makefile
--- a/arch/powerpc/platforms/44x/Makefile
+++ b/arch/powerpc/platforms/44x/Makefile
@@ -1,4 +1,4 @@ obj-$(CONFIG_44x) := misc_44x.o
-obj-$(CONFIG_44x) := misc_44x.o
+obj-$(CONFIG_44x) := misc_44x.o idle.o
obj-$(CONFIG_EBONY)+= ebony.o
obj-$(CONFIG_TAISHAN) += taishan.o
obj-$(CONFIG_BAMBOO) += bamboo.o
diff --git a/arch/powerpc/platforms/44x/idle.c
b/arch/powerpc/platforms/44x/idle.c
new file mode 100644
--- /dev/null
+++ b/arch/powerpc/platforms/44x/idle.c
@@ -0,0 +1,76 @@
+/*
+ * Copyright 2008 IBM Corp.
+ *
+ * Based on arch/powerpc/platforms/pasemi/idle.c:
+ * Copyright (C) 2006-2007 PA Semi, Inc
+ *
+ * Added by: Jerone Young [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ */
+
+#include linux/of.h
+#include linux/kernel.h
+#include asm/machdep.h
+
+static int current_mode;
+
+struct sleep_mode {
+ char *name;
+ void (*entry)(void);
+};
+
+static void ppc44x_idle(void)
+{
+ unsigned long msr_save;
+
+ msr_save = mfmsr();
+ /* set wait state MSR */
+ mtmsr(msr_save|MSR_WE|MSR_EE|MSR_CE|MSR_DE);
+ isync();
+ /* return to initial state */
+ mtmsr(msr_save);
+ isync();
+}
+
+static struct sleep_mode modes[] = {
+ { .name = wait, .entry = ppc44x_idle },
+ { .name = spin, .entry = NULL },
+};
+
+int __init ppc44x_idle_init(void)
+{
+ void *func = modes[current_mode].entry;
+ ppc_md.power_save = func;
+ return 0;
+}
+
+arch_initcall(ppc44x_idle_init);
+
+static int __init idle_param(char *p)
+{
+ int i;
+
+ for (i = 0; i ARRAY_SIZE(modes); i++) {
+ if (!strcmp(modes[i].name, p)) {
+ current_mode = i;
+ break;
+ }
+ }
+
+ return 0;
+}
+
+early_param(idle, idle_param);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
Paul Mackerras wrote: Kamalesh Babulal writes: The kernel oops after applying the patch. Some time it takes more than one run to reproduce it, it was reproducible in the second run this time. Unrecoverable exception 4100 at c0008c8c Oops: Unrecoverable exception, sig: 6 [#1] SMP NR_CPUS=128 NUMA pSeries Modules linked in: NIP: c0008c8c LR: 0ff0135c CTR: 0ff012f0 REGS: c00772343bb0 TRAP: 4100 Not tainted (2.6.25-rc8-autotest) MSR: 80001030 ME,IR,DR CR: 44044228 XER: TASK = c0077cfa0900[13437] 'cc1' THREAD: c0077234 CPU: 2 GPR00: 4000 c00772343e30 00bb d032 GPR04: 00bb 0400 000a 0002 GPR08: GPR12: c0734000 0064 ffe6df08 GPR16: 105b 105b 1044 105b GPR20: ffe6e008 105b 105b 000a GPR24: 0ffec408 0001 ffe6ddca 0400 GPR28: 0ffec408 f7ff8000 0ffebff4 0400 NIP [c0008c8c] restore+0x8c/0xc0 LR [0ff0135c] 0xff0135c Call Trace: [c00772343e30] [c0008cd4] do_work+0x14/0x2c (unreliable) Instruction dump: 7c840078 7c810164 70604000 41820028 6000 7c4c42e6 e88d01f0 f84d01f0 7c841050 e84d01e8 7c422214 f84d01e8 e9a100d8 7c7b03a6 e84101a0 7c4ff120 snip The exception happened at c...8c8c but you looked at c...8cdc with gdb. What's at c...8c8c? please let me know if you need more information. The .config would be useful, but don't spam everyone on cc with it, just send it to me privately. Paul. Hi Paul, Similar call trace was seen in 2.6.24-rc3-git2 kernel while bootup, I have attached the boot log to bugzilla (http://bugzilla.kernel.org/attachment.cgi?id=15666action=view). When looking for the last good one, we found that the kernel oops seems to be reproducible from the 2.6.24-rc8-git3 kernel onwards. Thanks to nishanth for pointing it out, Please let me know if you need more information. -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] tg3: fix for PPC 44x platforms
The driver stores the the PCI resource addresses into 'unsigned long' variable
before calling ioremap() on them. This warrants kernel oops when the registers
are accesse on PPC 44x platforms which (being 32-bit) have PCI memory space
mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion of the
PCI I/O and memory resources are mapped below 4 GB, but arch/powerpc/ code got
rid of this trick, having instead CONFIG_RESOURCES_64BIT enabled.
Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED]
---
This is the same issue as the one that has been recently addressed by commits
3c34ac36ac1084e571ef9b6fb1d6a5b10ccc1fd0 (e1000: Fix for 32 bits platforms with
64 bits resources) and c976816b6e901341ec3c4653147316c15549a1c4 (siimage: fix
kernel oops on PPC 44x). The patch has only been compile tested though...
drivers/net/tg3.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/net/tg3.c
===
--- linux-2.6.orig/drivers/net/tg3.c
+++ linux-2.6/drivers/net/tg3.c
@@ -12578,7 +12578,8 @@ static int __devinit tg3_init_one(struct
const struct pci_device_id *ent)
{
static int tg3_version_printed = 0;
- unsigned long tg3reg_base, tg3reg_len;
+ resource_size_t tg3reg_base;
+ unsigned long tg3reg_len;
struct net_device *dev;
struct tg3 *tp;
int err, pm_cap;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [kvm-ppc-devel] [PATCH] [v5] Add idle wait support for 44x platforms
On Tuesday 08 April 2008 11:49:14 Jerone Young wrote: 2 files changed, 77 insertions(+), 1 deletion(-) arch/powerpc/platforms/44x/Makefile |2 arch/powerpc/platforms/44x/idle.c | 76 +++ Updates: Now setting MSR_WE is now default Tested on hardware platforms bamboo sequioa and appears things are working fine on actually hardware! This patch adds the ability for the CPU to go into wait state while in cpu_idle loop. This helps virtulization solutions know when the guest Linux kernel is in an idle state. There are two ways to do it. Command line idle=spin -- CPU will spin idle=wait -- set CPU into wait state when idle (default) Signed-off-by: Jerone Young [EMAIL PROTECTED] Acked-by: Hollis Blanchard [EMAIL PROTECTED] -- Hollis Blanchard IBM Linux Technology Center ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: MPC8343 - unable to handle paging request @ 0
Scott Wood wrote: On Tue, Apr 08, 2008 at 03:50:26PM +0200, Andre Schwarz wrote: after building a debug kernel and attaching the bdi2000 it looks like the crash occurs during console_init() ... Does your device tree have a /chosen node after u-boot is done with it? find_legacy_serial_ports() can crash otherwise (we really should fix that). latest u-boot does add the chosen node. As far as I know it's for initrd setup ... don't know if it's complete. Since we're using a dtb I omit the console=... argument for the kernel. Is this correct ? It's OK if you have /chosen/linux,stdout-path. that sounds promising ! Haven't seen this and will have a closer look. If console=/dev/ttyS0,115200N8 argument is given the serial console stops working after console_init On other PowerPC system I could see something like this during boot : - find_legacy_serial_port() stdout is /[EMAIL PROTECTED]/[EMAIL PROTECTED] legacy_serial_console = 1 default console speed = 115340 - find_legacy_serial_port() Should I see this message also ? Only if you enable debug messages in legacy_serial.c. ok. Have I misconfigured anything ? One thing that sticks out from the above is that you ask for ttyS0, but the stdout you list from the other system corresponds to ttyS1. Is this just a difference between the two systems? Yes - the log from the MPC8568 is a copypaste from another posting. It's not my system. I want ttyS0. -Scott I appreciate your help ! Thanks, André MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler - Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] natsemi: fix for PPC 44x platforms
The driver stores the the PCI resource address into 'unsigned long' variable
before calling ioremap() on it. This warrants kernel oops when the registers
are accessed on PPC 44x platforms which (being 32-bit) have PCI memory space
mapped beyond 4 GB.
The arch/ppc/ kernel has a fixup in ioremap() that creates an illusion of the
PCI I/O and memory resources are mapped below 4 GB, but arch/powerpc/ code got
rid of this trick, having instead CONFIG_RESOURCES_64BIT enabled.
Signed-off-by: Sergei Shtylyov [EMAIL PROTECTED]
---
This is the same issue as the one that has been recently addressed by commits
3c34ac36ac1084e571ef9b6fb1d6a5b10ccc1fd0 (e1000: Fix for 32 bits platforms with
64 bits resources) and c976816b6e901341ec3c4653147316c15549a1c4 (siimage: fix
kernel oops on PPC 44x). The patch has only been compile tested though...
drivers/net/natsemi.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
Index: linux-2.6/drivers/net/natsemi.c
===
--- linux-2.6.orig/drivers/net/natsemi.c
+++ linux-2.6/drivers/net/natsemi.c
@@ -786,7 +786,8 @@ static int __devinit natsemi_probe1 (str
struct netdev_private *np;
int i, option, irq, chip_idx = ent-driver_data;
static int find_cnt = -1;
- unsigned long iostart, iosize;
+ resource_size_t iostart;
+ unsigned long iosize;
void __iomem *ioaddr;
const int pcibar = 1; /* PCI base address register */
int prev_eedata;
@@ -946,9 +947,9 @@ static int __devinit natsemi_probe1 (str
goto err_create_file;
if (netif_msg_drv(np)) {
- printk(KERN_INFO natsemi %s: %s at %#08lx
+ printk(KERN_INFO natsemi %s: %s at %#08llx
(%s), %s, IRQ %d,
- dev-name, natsemi_pci_info[chip_idx].name, iostart,
+ dev-name, natsemi_pci_info[chip_idx].name, (u64)iostart,
pci_name(np-pci_dev), print_mac(mac, dev-dev_addr),
irq);
if (dev-if_port == PORT_TP)
printk(, port TP.\n);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on mpc52xx_common.c
On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote: It may be ideal, but I don't think it is realistic. I'm now of the firm opinion that device trees and firmware are *never* perfect. Especially when the definition of perfect is a moving target. Well observed; isn't this the prove of the assumption that the whole device tree idea is not working? It is *always* inconsistent and it is *maintenance hell* because out-of-tree ports do *always* breakt because of string inconsistencies. We have just ported a 8260 board from 2.6.22 to 2.6.25 and it is almost 100% oftree porting. And you do not even have a single point of a parser, because all this string parsing is completely scattered all over the tree. The ARM method of using just a device number is so much easier ... Robert -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. 2, 31134 Hildesheim, Germany Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9 ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on mpc52xx_common.c
Robert Schwebel wrote: Well observed; isn't this the prove of the assumption that the whole device tree idea is not working? It is *always* inconsistent and it is *maintenance hell* because out-of-tree ports do *always* breakt because of string inconsistencies. We have just ported a 8260 board from 2.6.22 to 2.6.25 and it is almost 100% oftree porting. There's going to be more churn in the initial stages than down the road. 82xx had barely been added to arch/powerpc in 2.6.22, and there was little review of the initial device tree bindings. The ARM method of using just a device number is so much easier ... Yeah, it's so much fun to have to allocate a globally unique number for every minor tweak of a board, and to have to maintain a mapping from said numbers to information that is semantically equivalent to a device tree but in less maintainable form in the kernel source. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on mpc52xx_common.c
Robert Schwebel wrote: The ARM method of using just a device number is so much easier ... And I was going to suggest that the ARM guys should use device trees, too. -- Timur Tabi Linux kernel developer at Freescale ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
On Fri, 2008-04-04 at 08:38 +0200, Arnd Bergmann wrote: On Wednesday 02 April 2008, Carl Love wrote: On Wed, 2008-04-02 at 07:21 +0200, Arnd Bergmann wrote: On Tuesday 25 March 2008, Carl Love wrote: This patch fixes a bug in the code that records the SPU data and context switches. The buffer_mutex lock must be held when the kernel is adding data to the buffer between the kernel and the OProfile daemon. The lock is not being held in the current code base. This patch fixes the bug using work queues. The data to be passed to the daemon is caputured by the interrupt handler. The workqueue function is invoked to grab the buffer_mutex lock and add the data to the buffer. So what was the exact bug you're fixing with this? There was no buffer_mutex before, so why do you need it now? Can't this be a spinlock so you can get it from interrupt context instead of using a workqueue? The generic OProfile code defines a mutex lock, called buffer_mutex, to protect the kernel/daemon data buffer from being writen by the kernal and simultaneously read by the Daemon. When adding a PPU sample the oprofile routine oprofile_add_ext_sample(pc, regs, i, is_kernel) is called from the interrupt context to request the sample be stored. The generic oprofile code takes care of passing the data to a non interrupt context where the mutex lock is held and the necessary sequence of data is written into the kernel/daemon data buffer. However, OProfile does not have any built in functions for handling the SPU. Hence, we have to implement the code to capture the data in the interrupt context, pass it to a non interrupt context and put it into the buffer. This was not done correctly in the original implementation. Specifically, the mutex lock was not being held. Ok, I see. However, I'm pretty sure that the switch notification does not get called from an atomic context, so you don't need a workqueue for bringing that into a process context. Doing the context switch notification directly from the scheduler sounds much better regarding the impact on the measurement. Our first thought to fix the bug was to just grab the mutex lock when adding the switch notification data to the queue. The kernel gives us an oops message saying something along the line of could not call mutex lock in interrupt context. Hence we had to go to work queues so we could access the lock outside of the SPU switch notification context. Secondly, it is my understanding that if the schedule_work() call tries to queue the same work function multiple times the subsequent requests are dropped. Thus we were not able to pass the context switch data as part of the schedule work requests. This forced us to have an array to store the data for each SPU. Never put extern statements in the implementation, they describe the interface between two parts of the code and should be inside of a common header. Why do you want to have your own workqueue instead of using the global one? It is important that the data get context switch data get recorded as quickly as possible to avoid dropping data unnecessarily. The PC counter data for each SPU is ignored until the context switch record is put into the kernel/daemon buffer. The API documentation says that using a private workqueue has better performance then using the global workqueue. There is a comment in the code about this, perhaps it is not clear enough. This sounds like an unrelated bug in the implementation. The PC data should *not* be ignored in any case. As long as the records get stored in the right order, everything should be fine here. Until the OProfile sees the context switch record, it does not know what to do with the PC samples and just drops them. The thought was using a private work queue might help get the context switch records processed a little earlier. It probably doesn't make that much difference. I can just use the generic work queue. This looks like you want to use a delayed_work rather than building your own out of hrtimer and work. Is there any point why you want to use an hrtimer? The current implementation uses the hrtimer to schedule when to read the trace buffer the next time. This patch does not change how the scheduling of the buffer reads is done. Yes, you could change the implementation to use workqueues instead. If you feel that it is better to use the workqueue then we could make that change. Not sure that making that change in this bug fix patch is appropriate. I would need to create a second patch for that change. I would guess that the change from hrtimer to delayed_workqueue is smaller than the current patch changing from hrtimer to hrtimer plus workqueue, so I would prefer to have only one changeset. Since the timer only causes statistical data collection anyway, delaying it a bit should
Re: Question on mpc52xx_common.c
On Tue, Apr 8, 2008 at 1:45 PM, Robert Schwebel [EMAIL PROTECTED] wrote: On Tue, Apr 08, 2008 at 08:52:55AM -0600, Grant Likely wrote: It may be ideal, but I don't think it is realistic. I'm now of the firm opinion that device trees and firmware are *never* perfect. Especially when the definition of perfect is a moving target. Well observed; isn't this the prove of the assumption that the whole device tree idea is not working? It is *always* inconsistent and it is *maintenance hell* because out-of-tree ports do *always* breakt because of string inconsistencies. We have just ported a 8260 board from 2.6.22 to 2.6.25 and it is almost 100% oftree porting. And you do not even have a single point of a parser, because all this string parsing is completely scattered all over the tree. I disagree and that is not my point. My point is that perfection is neither obtainable or necessary. Many of the recently established embedded guidelines are not perfect because they are counter to a few of the OF recommended practices. However, they are consistent within themselves, they work, and once established they are not going to change. imperfect != bad. I brought up a new 5200 board this week which required zero kernel changes. All I needed was a new dt to describe the board. Now, if out-of-tree ports continue to break then we've got a problem that needs to be fixed. Once a binding is established (which usually takes a few kernel releases) it should be very stable and even if the definition of ideal is changed, backwards compatibility must be maintained. The ARM method of using just a device number is so much easier ... Only if the assumption is made that very little data needs to be shared between the kernel and the firmware. The moment you try to do something more complex you either have the nightmare of bd_info or you use a structured data format (like the device tree) On another node, there are platforms where a device number is unworkable. For example, for Linux on an FPGA like the Xilinx Virtex, there would need to be a new platform number every time the FPGA bitstream was updated because it is effectively an entirely different platform. Finally, using a device number means you need to encode into the kernel the exact layout of every platform it supports. That adds up to a lot of code in a real hurry; even if most of it is just boilerplate instantiations. Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH] ata: Fix pata SIL680 build on arch/ppc
Commit 0f436eff54f90419ac1b8accfb3e6e17c4b49a4e breaks build on arch/ppc as it doesn't implement the machine_is() macro. This fixes it by using CONFIG_PPC_MERGE instead which represents arch/powerpc only, while CONFIG_PPC is set for both. Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED] --- Index: linux-work/drivers/ata/pata_sil680.c === drivers/ata/pata_sil680.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-work.orig/drivers/ata/pata_sil680.c 2008-04-09 07:47:23.0 +1000 +++ linux-work/drivers/ata/pata_sil680.c2008-04-09 07:47:29.0 +1000 @@ -270,7 +270,7 @@ static u8 sil680_init_chip(struct pci_de tmpbyte 1, tmpbyte 0x30); *try_mmio = 0; -#ifdef CONFIG_PPC +#ifdef CONFIG_PPC_MERGE if (machine_is(cell)) *try_mmio = (tmpbyte 1) || pci_resource_start(pdev, 5); #endif ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc440 caches - change proposal [RFC]
On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote: I was thinking it might be good to have the kernel initialize these cache control registers in it's own start up code. Or perhaps this could be done in the kernel's simple bootloader. We could probably put this change in a Xilinx specific startup file, but this change doesn't seem specific to Xilinx FPGA boards. The kernel's wrapper would be a good place to put that I suspect. That's the kind of thing that should be provided as a library function to be optionally called by platform code. Either in the wrapper or the main kernel platform code. Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc440 caches - change proposal [RFC]
On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote: I was thinking it might be good to have the kernel initialize these cache control registers in it's own start up code. Or perhaps this could be done in the kernel's simple bootloader. We could probably put this change in a Xilinx specific startup file, but this change doesn't seem specific to Xilinx FPGA boards. The kernel's wrapper would be a good place to put that I suspect. That's the kind of thing that should be provided as a library function to be optionally called by platform code. Either in the wrapper or the main kernel platform code. Code is already queued up for 2.6.26 to do exactly this on ppc405 virtex platforms. We can do the same thing for 440. Look at virtex405-head.S in the following patch: http://patchwork.ozlabs.org/linuxppc/patch?person=486id=17410 Cheers, g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: Question on mpc52xx_common.c
On Tue, Apr 08, 2008 at 03:07:58PM -0500, Scott Wood wrote: Robert Schwebel wrote: Well observed; isn't this the prove of the assumption that the whole device tree idea is not working? It is *always* inconsistent and it is *maintenance hell* because out-of-tree ports do *always* breakt because of string inconsistencies. We have just ported a 8260 board from 2.6.22 to 2.6.25 and it is almost 100% oftree porting. There's going to be more churn in the initial stages than down the road. 82xx had barely been added to arch/powerpc in 2.6.22, and there was little review of the initial device tree bindings. The ARM method of using just a device number is so much easier ... Yeah, it's so much fun to have to allocate a globally unique number for every minor tweak of a board, and to have to maintain a mapping from said numbers to information that is semantically equivalent to a device tree but in less maintainable form in the kernel source. And we can already do device numbers if we really want. A bootwrapper that identifies the board and supplies a device tree essentially does that, and that way the device tree is maintained in sync with the kernel. This is why I've always had mixed feelings about merging device trees into u-boot, rather than having them supplied by the wrapper. -- David Gibson| I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: ppc440 caches - change proposal [RFC]
On Tue, 8 Apr 2008 17:15:44 -0600 Grant Likely [EMAIL PROTECTED] wrote: On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote: I was thinking it might be good to have the kernel initialize these cache control registers in it's own start up code. Or perhaps this could be done in the kernel's simple bootloader. We could probably put this change in a Xilinx specific startup file, but this change doesn't seem specific to Xilinx FPGA boards. The kernel's wrapper would be a good place to put that I suspect. That's the kind of thing that should be provided as a library function to be optionally called by platform code. Either in the wrapper or the main kernel platform code. Code is already queued up for 2.6.26 to do exactly this on ppc405 virtex platforms. We can do the same thing for 440. Look at virtex405-head.S in the following patch: http://patchwork.ozlabs.org/linuxppc/patch?person=486id=17410 That patch is already in Paul's tree btw. As for 440, yes it might be good to init the cache registers in the wrapper. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [Cbe-oss-dev] [PATCH] Cell OProfile: SPU mutex lock fix
On Tuesday 08 April 2008, Carl Love wrote: On Fri, 2008-04-04 at 08:38 +0200, Arnd Bergmann wrote: Our first thought to fix the bug was to just grab the mutex lock when adding the switch notification data to the queue. The kernel gives us an oops message saying something along the line of could not call mutex lock in interrupt context. Hence we had to go to work queues so we could access the lock outside of the SPU switch notification context. By the time the notifier is called, the kernel is certainly not in an atomic context. Maybe you were nesting the mutex lock inside of your own spinlock? Secondly, it is my understanding that if the schedule_work() call tries to queue the same work function multiple times the subsequent requests are dropped. Thus we were not able to pass the context switch data as part of the schedule work requests. This forced us to have an array to store the data for each SPU. The way that work queues are designed, you embed the struct work in the data you pass down, so that you are guaranteed to execute the work struct exactly once per data element and you don't need any global pointers. I would guess that the change from hrtimer to delayed_workqueue is smaller than the current patch changing from hrtimer to hrtimer plus workqueue, so I would prefer to have only one changeset. Since the timer only causes statistical data collection anyway, delaying it a bit should not have any negative effect on the accuracy of the measurement, unlike delaying the context switch notification. The goal is to be able to support very high sampling rates (small periods). The schedule_delayed_work() is based on jiffies which I believe is 1/250 for this machine. This only gives millisecond resolution. The goal is for the users to be able to specify a time period of 60,000 cycles or less then 20 micro second sampling periods when the real high resolution timers are available. We can't achieve the desired sampling rates with the schedule_dealyed_work() function. You actually can't get anywhere close to that resolution if you do your data collection in a work queue, because under high load (which is what the only time when measuring really gets interesting) the work queue is likely to be delayed by a few jiffies! If you rely on high resolution timer precision, you need to look at the performance counters from inside the timer function, and deal with the problem of the work queue not being called for a number of timer events. Oprofile provides nice clean interfaces for recording kernel/user switches and CPU data recording. This is all that was needed by any architecture until CELL came along. With CELL, we now have need to add processor data plus SPU data to the queue. The buffer_mutex variable and the add_event_entry() were not visible outside of the OProfile driver code. The original SPU support added add_event_entry() to the include/linux/oprofile.h file. We can add the buffer_mutex as well since there is now a need to access both of these. I have been looking to see how I could create a generic oprofile routine which could take the data. The routine would still have to work from an interrupt context, so it will need to store the data and call a work queue function. The function would need to know how much data will be needed, thus you would probably need to statically allocate data or use a list and malloc the data as needed. I don't really want to have to malloc data from an interrupt context. List management adds additional overhead. It would be possible to have an init function that you could call at startup time telling it how much memory you need, in this case we could allocate a buffer the size of spu_info (defined below) at startup time. The call could pass an array to the OProfile routine that would put the data into the buffer and call the work function. We still have to allocate the storage, it does clean up the arch specific code. Not sure if this really buys us much. There is more copying of data i.e. more overhead. Not convinced the OProfile maintainers would accept anything I have thought of so far. Any suggestions? My first attempt to do this would be to add this to the oprofile/cpu_buffer.c infrastructure. Basically extend the add_sample() function to have helpers you can call from the spu code to put entries into the per-cpu buffer of the CPU that happens to execute the code at the time. add_sample() can already be called from an atomic context since it uses its own buffer, and it uses a clever ring buffer to get around the need for locking against the event_buffer functions. Only event_buffer needs the mutex, so it's best to leave that out of the architecture code running at interrupt time altogether. An ideal driver should not have *any* global variables at all, but store all data in the (reference counted) objects it is dealing with, or just on the stack while it's processing
[PATCH] [POWERPC] Make pci_bus_to_host()'s struct pci_bus * argument const
Why? Because:
A) It's not modified and so it can be made const. const is good.
B) If one has a function that was given a const pci_bus pointer and you
want to get a pointer to its pci_controller, you'll get a warning from gcc
when you use pci_bus_to_host(). This is the right way to stop that
warning.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
---
include/asm-powerpc/pci-bridge.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/pci-bridge.h b/include/asm-powerpc/pci-bridge.h
index e5802c6..b95d033 100644
--- a/include/asm-powerpc/pci-bridge.h
+++ b/include/asm-powerpc/pci-bridge.h
@@ -117,7 +117,7 @@ struct pci_controller {
#ifndef CONFIG_PPC64
-static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
+static inline struct pci_controller *pci_bus_to_host(const struct pci_bus *bus)
{
return bus-sysdata;
}
@@ -235,7 +235,7 @@ extern void pcibios_fixup_new_pci_devices(struct pci_bus
*bus);
extern int pcibios_remove_root_bus(struct pci_controller *phb);
-static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
+static inline struct pci_controller *pci_bus_to_host(const struct pci_bus *bus)
{
struct device_node *busdn = bus-sysdata;
--
1.5.4.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: 4xx defconfig reorg
On Mon, 2008-04-07 at 16:36 -0500, Kumar Gala wrote: On Apr 6, 2008, at 8:06 AM, Josh Boyer wrote: Hi All, Unless someone screams loudly and has reasons why this shouldn't go in, the following commit should hit the 4xx next branch in the next day or so. josh If this is acceptable to people, I'll make similar defconfig movements for the Freescale parts. I've not heard any objections. I'll be pushing my commit to my next branch tomorrow morning. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] [POWERPC] Make pci_bus_to_host()'s struct pci_bus * argument const
On Tue, 2008-04-08 at 19:19 -0700, Trent Piepho wrote:
Why? Because:
A) It's not modified and so it can be made const. const is good.
B) If one has a function that was given a const pci_bus pointer and you
want to get a pointer to its pci_controller, you'll get a warning from gcc
when you use pci_bus_to_host(). This is the right way to stop that
warning.
Signed-off-by: Trent Piepho [EMAIL PROTECTED]
Acked-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
---
include/asm-powerpc/pci-bridge.h |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/asm-powerpc/pci-bridge.h
b/include/asm-powerpc/pci-bridge.h
index e5802c6..b95d033 100644
--- a/include/asm-powerpc/pci-bridge.h
+++ b/include/asm-powerpc/pci-bridge.h
@@ -117,7 +117,7 @@ struct pci_controller {
#ifndef CONFIG_PPC64
-static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
+static inline struct pci_controller *pci_bus_to_host(const struct pci_bus
*bus)
{
return bus-sysdata;
}
@@ -235,7 +235,7 @@ extern void pcibios_fixup_new_pci_devices(struct pci_bus
*bus);
extern int pcibios_remove_root_bus(struct pci_controller *phb);
-static inline struct pci_controller *pci_bus_to_host(struct pci_bus *bus)
+static inline struct pci_controller *pci_bus_to_host(const struct pci_bus
*bus)
{
struct device_node *busdn = bus-sysdata;
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [BUG] 2.6.25-rc2-git4 - Regression Kernel oops while running kernbench and tbench on powerpc
Paul Mackerras wrote: Kamalesh Babulal writes: The kernel oops after applying the patch. Some time it takes more than one run to reproduce it, it was reproducible in the second run this time. Unrecoverable exception 4100 at c0008c8c Oops: Unrecoverable exception, sig: 6 [#1] SMP NR_CPUS=128 NUMA pSeries Modules linked in: NIP: c0008c8c LR: 0ff0135c CTR: 0ff012f0 REGS: c00772343bb0 TRAP: 4100 Not tainted (2.6.25-rc8-autotest) MSR: 80001030 ME,IR,DR CR: 44044228 XER: TASK = c0077cfa0900[13437] 'cc1' THREAD: c0077234 CPU: 2 GPR00: 4000 c00772343e30 00bb d032 GPR04: 00bb 0400 000a 0002 GPR08: GPR12: c0734000 0064 ffe6df08 GPR16: 105b 105b 1044 105b GPR20: ffe6e008 105b 105b 000a GPR24: 0ffec408 0001 ffe6ddca 0400 GPR28: 0ffec408 f7ff8000 0ffebff4 0400 NIP [c0008c8c] restore+0x8c/0xc0 LR [0ff0135c] 0xff0135c Call Trace: [c00772343e30] [c0008cd4] do_work+0x14/0x2c (unreliable) Instruction dump: 7c840078 7c810164 70604000 41820028 6000 7c4c42e6 e88d01f0 f84d01f0 7c841050 e84d01e8 7c422214 f84d01e8 e9a100d8 7c7b03a6 e84101a0 7c4ff120 That looks like the bug that was supposed to be fixed by commit 44387e9ff25267c78a99229aca55ed750e9174c7, which is in 2.6.25-rc7 and later. What was the SHA1 ID of the head commit for the kernel source that gave you this oops? Did you have any other patches besides the one I sent you applied? Paul. The SHA1 ID of the kernel is 0e81a8ae37687845f7cdfa2adce14ea6a5f1dd34 (2.6.25-rc8) and the source seems to have the patch 44387e9ff25267c78a99229aca55ed750e9174c7. The kernel was patched only the patch you gave me (http://lkml.org/lkml/2008/4/8/42). -- Thanks Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
