* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Heiko J Schick @ 2006-05-05 13:05 UTC (permalink / raw)
To: Roland Dreier
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <adaejz9o4vh.fsf@cisco.com>
Hello Roland,
Roland Dreier wrote:
> It seems that you are deferring completion event dispatch into threads
> spread across all the CPUs. This seems like a very strange thing to
> me -- you are adding latency and possibly causing cacheline pingpong.
>
> It may help throughput in some cases to spread the work across
> multiple CPUs but it seems strange to me to do this in the low-level
> driver. My intuition would be that it would be better to do this in
> the higher levels, and leave open the possibility for protocols that
> want the lowest possible latency to be called directly from the
> interrupt handler.
We've implemented this "spread CQ callbacks across multiple CPUs"
functionality to get better throughput on a SMP system, as you have
seen.
Originaly, we had the same idea as you mentioned, that it would be better
to do this in the higher levels. The point is that we can't see so far
any simple posibility how this can done in the OpenIB stack, the TCP/IP
network layer or somewhere in the Linux kernel.
For example:
For IPoIB we get the best throughput when we do the CQ callbacks on
different CPUs and not to stay on the same CPU.
In other papers and slides (see [1]) you can see similar approaches.
I think such one implementation or functionality could require more
or less a non-trivial changes. This could be also releated to other
I/O traffic.
[1]: Speeding up Networking, Van Jacobson and Bob Felderman,
http://www.lemis.com/grog/Documentation/vj/lca06vj.pdf
Regards,
Heiko
^ permalink raw reply
* Some issues while booting the 2.6.13.4 kernel on PPC440GR with CMD649 IDE
From: vinay hegde @ 2006-05-05 11:37 UTC (permalink / raw)
To: linuxppc-embedded
Hi All,
I am porting the 2.6.13.4 kernel to PPC440GR board.
When I try to boot the kernel with CMD649 IDE support
enabled, I get kernel panic. Without CMD649, the
kernel boots just fine.
I read the PCI config space from the driver (inside
do_ide_setup_pci_device function) and verified that
DEVICE id,VENDOR id and interrupt lines are correct.
However, bar address does not seem to be correct
(actual phy and virtual set while PCI bridge config is
0xa0000000). Below is the kernel boot log for
reference:
>>>>>>>>>>>>>>>>>
..........
..........
ide: Assuming 33MHz system bus speed for PIO modes;
override with idebus=xx
CMD649: IDE controller at PCI slot 0000:00:0c.0
CMD649: chipset revision 1
CMD649: 100% native mode on irq 25
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR=
0x360eff98
POB0: BEAR=0xc27e3194fefcfc9f BESR0=0x00000000
BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#1]
NIP: 00000000 LR: C0106024 SP: C1981EC0 REGS: c026af50
TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = c1134b10[1] 'swapper' THREAD: c1980000
Last syscall: 120
GPR00: FDFFEFD2 C1981EC0 C1134B10 00000000 00000060
FDFEE004 00000002 C1981EA8
GPR08: 00000000 C0270000 00000008 FDFEE004 00000000
30000000 C0277CB0 C0277CB0
GPR16: C0277CB0 00000019 00000000 C0277CB0 C0277CB0
C1130000 C1981F58 C1130000
GPR24: C0265A2A C1130000 00000000 0000FFD0 C0265A08
40000000 C0277CB0 C0277CB0
NIP [00000000] 0x0
LR [c0106024] ide_pci_setup_ports+0x61c/0x71c
Call trace:
[c010633c] do_ide_setup_pci_device+0x218/0x464
[c01065a8] ide_setup_pci_device+0x20/0x9c
[c02298d0] cmd64x_init_one+0x24/0x34
[c022a2f0] ide_scan_pcidev+0x80/0xc4
[c022a360] ide_scan_pcibus+0x2c/0xf8
[c022a24c] ide_init+0x58/0x7c
[c0001868] init+0x7c/0x2cc
[c0004b90] kernel_thread+0x48/0x64
Data machine check in kernel mode.
PLB0: BEAR=0x0000000000000000 ACR= 0x00000000 BESR=
0x360eff98
POB0: BEAR=0xc27e3194fefcfc9f BESR0=0x00000000
BESR1=0x00000000
OPB0: BEAR=0x0000000000000151 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C00028DC SP: C026AE70 REGS: c026af50
TRAP: 0202 Not tainted
MSR: 00000000 EE: 0 PR: 0 FP: 0 ME: 0 IR/DR: 00
TASK = c1134b10[1] 'swapper' THREAD: c1980000
Last syscall: 120
GPR00: 08000000 C026AE70 C1134B10 C026AE80 00000C1B
FFFFFFFF C0270000 C01E511C
GPR08: C01E0000 C00028DC 00021002 C0003CDC C1134CD8
30000000 C0277CB0 C0277CB0
GPR16: C0277CB0 00000019 00000000 C0277CB0 C0277CB0
C1130000 C1981F58 C1130000
GPR24: C0265A2A C1130000 00000000 0000FFD0 C0265A08
40000000 C026AF50 00000007
NIP [00000000] 0x0
LR [c00028dc] ret_from_except+0x0/0x18
Kernel panic - not syncing: Attempted to kill init!
<0>Rebooting in 180 seconds..
<<<<<<<<<<<<<<<<<
This is what I get when I print some PCI config space
parameters:
>>>>>>>>>>>>>
VENDOR ID: 0x1095
DEVICE ID: 0x0649
INTERRUPT LINE: 0x1C
REVISION: 0x01
BASE REG 0 is: 0x0000FFF0
BASE REG 1 is: 0x0000FFF0
BASE REG 2 is: 0x0000FFE0
BASE REG 3 is: 0x0000FFE0
<<<<<<<<<<<<
The "pci" command from u-Boot shows the following:
>>>>>>>>>>
=> pci
Scanning PCI devices on bus 0
BusDevFun VendorId DeviceId Device Class
Sub-Class
______________________________________________________00.00.00
0x1014 0x027f Bridge device 0x80
00.0c.00 0x1095 0x0649 Mass storage
controller 0x04
=>
<<<<<<<<<<
I enabled the following for CMD649 in kernel
configuration:
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_CMD64X=y
CONFIG_BLK_DEV_IDEDMA=y
Please let me know if - anybody has seen this error
before/knows the fix for this issue.
Thanks for the help.
-Vinay.
____________________________________________________
Yahoo! India Answers: Share what you know. Learn something new. http://in.answers.yahoo.com
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: Wolfgang Denk @ 2006-05-05 9:40 UTC (permalink / raw)
To: Gautam Borad; +Cc: linuxppc-embedded
In-Reply-To: <445B1019.9010103@eisodus.com>
In message <445B1019.9010103@eisodus.com> you wrote:
>
...
> We have tested the SDRAM in both U-boot (mtest) and linux, and the tests
> doesnt show anything
> wrong with the SDRAM.
No, of course not. Please read the FAQ to understand why standard RAM
tests will never detect this type of problem.
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Here is an Appalachian version of management's answer to those who
are concerned with the fate of the project: "Don't worry about the
mule. Just load the wagon." - Mike Dennison's hillbilly uncle
^ permalink raw reply
* Re: [PATCH 07/13] powerpc: export symbols for page size selection
From: Arnd Bergmann @ 2006-05-05 9:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <17498.59681.133131.336680@cargo.ozlabs.ibm.com>
On Friday 05 May 2006 07:56, Paul Mackerras wrote:
> I don't like exporting low-level implementation details like this, and
> it seems a bit bogus to have an SLB miss handler in a module. Could
> you move the SLB miss handler to the non-modular part?
Yes. The series already has the patches to move the SLB miss handler
into the built-in parts. At the moment, we also need the symbols for
the context switch code that also touches the SLB entries. We already
have a patch to move that as well, but are still discussing the details
of that.
I'll follow up with a patch to replace this one.
Arnd <><
^ permalink raw reply
* Re: frequent sig 11 with malloc() on mpc8xx
From: Gautam Borad @ 2006-05-05 8:43 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20060504144605.B18B3353BE7@atlas.denx.de>
Wolfgang Denk wrote:
>In message <4459B1CF.60909@eisodus.com> you wrote:
>
>
>>We are having a frequent sig 11 problem on our custom mpc852t board
>>with linux kernel 2.6.14 and U-boot version 1.1.3
>>
>>
>That's a FAQ.
>
>
>
>>I had the same problem with 2.4 kernel and after posting the problem
>>
>>
>This confirms that the FAQ matches your problem. See
>http://www.denx.de/wiki/view/DULG/LinuxCrashesRandomly
>
>
>
Thanks for the reply. We have checked the cpu sdram settings and would
re-check the sdram initialization sequence.
However the problem faced is following:
The sig. 11 is generated at a specific instance of accessing memory
areas in
range of 0x00000024 - 0x000000C8 (i.e low address range).
AFAIK this is assigned to kernel area.
We have a ptrintk in arch/ppc/mm/fault.c which shows the frequent page
fault
and its recovery from the fault, however as soon as the DAR loads
0x00000024
or such low address we get a sig. 11.
Bad emulation malloctest/657
NIP: 30000c10 instruction: 00000000 opcode: 0 A: 0 B: 0 C: 0 code: 0 rc: 0
pte @ 0x30000c10: (0xc1d3b300)->(0xc020f000)->0x01c2b889
RPN: 01c2b PP: 2 SPS: 1 SH: 0 CI: 0 v: 1
Kernel VA for NIP c1c2bc10 pte @ 0xc1c2bc10: no pmd
Oops: kernel access of bad area, sig: 11 [#1]
NIP: C00286C8 LR: C0186684 SP: C02CDCA0 REGS: c02cdbf0 TRAP: 0300 Not
tainted
MSR: 00001032 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000000, DSISR: C2000000
<======== here the DAR is 0x00000000
TASK = c1d0e070[657] 'malloctest' THREAD: c02cc000
We have tested the SDRAM in both U-boot (mtest) and linux, and the tests
doesnt show anything
wrong with the SDRAM.
thanks in advance.
^ permalink raw reply
* Bad page state in process 'swapper'
From: Richard Guinto @ 2006-05-05 8:18 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: argie_guinto
Hi,
I'm quoting here Grant's answer:
*****************************************
On 4/11/06, Vincent Winstead <vwinstead at yahoo.com>
wrote:
>
> I'm having a real difficulty trying to get linux
onto this board. So I'm
> finally turning to the community for help. The only
people that have
> documented their approach to putting open source
linux onto the ML310 board
> have used bitkeeper to download the kernel for the
project, but bitkeeper
> isn't used any more is it? I've been going straight
to kernel.org and
> getting kernels from there and crosscompiling them
on my machine to be
> transported to the ppc core on the ML310. Is this
wrong? Is there a patch
> or some kernel source that I don't know about for
PPC? Thanks!
Are you using 2.4 or 2.6?
Support for the ML300 & ML403 is in the mainline 2.6
git tree. As
long as you've got an xparameters.h file for your FPGA
bitstream, you
should be able to port a 2.6 kernel really easily.
If you want to use 2.4, you can pull the linuxppc
rsync mirror which
has ML300 support in it.
http://www.penguinppc.org/kernel/ (Look at the very
bottom of the
page for the RSYNC mirror)
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
*****************************************************
After changing the xparameters.h, I was able to boot
with the 2.6.16.13 kernel, which I got from
kernel.org, but then I'm having a "bad page" problem
as shown in the output below:
loaded at: 00400000 006011A0
board data at: 005FF124 005FF1A0
relocated to: 004051B4 00405230
zimage at: 0040592D 00495B48
initrd at: 00496000 005FEE44
avail ram: 00602000 04000000
Linux/PPC load: console=ttyS0,9600
Uncompressing Linux...done.
Now booting the kernel
Linux version 2.6.16.13 (root@rgdev) (gcc version
3.4.1) #19 Fri May 5 13:39:53 PHT 2006
Xilinx Virtex-II Pro port
Port by MontaVista Software, Inc. (source@mvista.com)
Built 1 zonelists
Kernel command line: console=ttyS0,9600
Xilinx INTC #0 at 0x41200000 mapped to 0xFDFFE000
PID hash table entries: 512 (order: 9, 8192 bytes)
Console: colour dummy device 80x25
Dentry cache hash table entries: 16384 (order: 4,
65536 bytes)
Inode-cache hash table entries: 8192 (order: 3, 32768
bytes)
Memory: 62060k available (908k kernel code, 364k data,
64k init, 0k highmem)
Bad page state in process 'swapper'
page:c01539c0 flags:0x00000080 mapping:00000000
mapcount:0 count:1
Trying to fix it up, but a reboot is needed
Backtrace:
Call Trace:
[C012DDF0] [C00094B4] show_stack+0x58/0x180
(unreliable)
[C012DE20] [C00452EC] bad_page+0x5c/0xa0
[C012DE40] [C0045DD0]
get_page_from_freelist+0x2cc/0x454
[C012DE90] [C0045FAC] __alloc_pages+0x54/0x278
[C012DED0] [C005869C] cache_alloc_refill+0x2e0/0x53c
[C012DF10] [C0058398] kmem_cache_alloc+0x50/0x74
[C012DF30] [C00594A8] kmem_cache_create+0x3a0/0x508
[C012DFA0] [C013846C] kmem_cache_init+0x180/0x3a0
[C012DFD0] [C012E5E4] start_kernel+0x138/0x1a4
[C012DFF0] [C000225C] start_here+0x44/0xb0
Now, I tried to debug the functions in the call trace,
and it seems that the prep_new_page function calls the
bad_page because the test for page_count(page) != 0 is
TRUE (count value is 1).
I know that the hardware or the memory is working
because I have 2.4.20 running. What could probably
cause this problem? Is there a patch for ml300
available to fix this?
Many thanks!!!
*
Richard
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [PATCH 04/13] cell: remove broken __setup_cpu_be function
From: Paul Mackerras @ 2006-05-05 6:03 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20060429233920.295209000@localhost.localdomain>
Arnd Bergmann writes:
> From: Geoff Levand <geoffrey.levand@am.sony.com>
>
> This patch removes the incorrect Cell processor setup routine
> __setup_cpu_be. This routine improperly accesses the hypervisor
> page size configuration at SPR HID6. The correct behavior is for
> firmware, or if needed, platform setup code, to set the correct
> page size.
> - .cpu_setup = __setup_cpu_be,
> + .cpu_setup = __setup_cpu_power4,
That looks a bit dodgy. Either just remove the contents of
__setup_cpu_be (leaving only the blr), or define a __setup_cpu_null
that does nothing, or make the identify_cpu not call the cpu setup
function if the pointer is NULL.
Paul.
^ permalink raw reply
* Re: [PATCH 07/13] powerpc: export symbols for page size selection
From: Paul Mackerras @ 2006-05-05 5:56 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: Arnd Bergmann, linuxppc-dev, cbe-oss-dev, linux-kernel
In-Reply-To: <20060429233921.099214000@localhost.localdomain>
Arnd Bergmann writes:
> We need access to some symbols in powerpc memory management
> from spufs in order to create proper SLB entries.
I don't like exporting low-level implementation details like this, and
it seems a bit bogus to have an SLB miss handler in a module. Could
you move the SLB miss handler to the non-modular part?
Regards,
Paul.
^ permalink raw reply
* [UPDATED] Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-05 5:00 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
to receive the following updates:
arch/powerpc/kernel/setup-common.c | 17 +++++++++++++++++
arch/powerpc/kernel/setup.h | 2 ++
arch/powerpc/kernel/setup_32.c | 5 +++--
arch/powerpc/kernel/setup_64.c | 18 +-----------------
4 files changed, 23 insertions(+), 19 deletions(-)
Kumar Gala:
powerpc: provide ppc_md.panic() for both ppc32 & ppc64
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 684ab1d..88de557 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -524,3 +524,20 @@ int check_legacy_ioport(unsigned long ba
return ppc_md.check_legacy_ioport(base_port);
}
EXPORT_SYMBOL(check_legacy_ioport);
+
+static int ppc_panic_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ ppc_md.panic(ptr); /* May not return */
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_panic_block = {
+ .notifier_call = ppc_panic_event,
+ .priority = INT_MIN /* may not return; must be done last */
+};
+
+void __init setup_panic(void)
+{
+ atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block);
+}
diff --git a/arch/powerpc/kernel/setup.h b/arch/powerpc/kernel/setup.h
index 2ebba75..e67066c 100644
--- a/arch/powerpc/kernel/setup.h
+++ b/arch/powerpc/kernel/setup.h
@@ -2,5 +2,7 @@ #ifndef _POWERPC_KERNEL_SETUP_H
#define _POWERPC_KERNEL_SETUP_H
void check_for_initrd(void);
+void do_init_bootmem(void);
+void setup_panic(void);
#endif /* _POWERPC_KERNEL_SETUP_H */
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 69ac257..88832b3 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -235,8 +235,6 @@ arch_initcall(ppc_init);
/* Warning, IO base is not yet inited */
void __init setup_arch(char **cmdline_p)
{
- extern void do_init_bootmem(void);
-
/* so udelay does something sensible, assume <= 1000 bogomips */
loops_per_jiffy = 500000000 / HZ;
@@ -285,6 +283,9 @@ #endif
/* reboot on panic */
panic_timeout = 180;
+ if (ppc_md.panic)
+ setup_panic();
+
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4467c49..ab6ea37 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -100,12 +100,6 @@ unsigned long SYSRQ_KEY;
#endif /* CONFIG_MAGIC_SYSRQ */
-static int ppc64_panic_event(struct notifier_block *, unsigned long, void *);
-static struct notifier_block ppc64_panic_block = {
- .notifier_call = ppc64_panic_event,
- .priority = INT_MIN /* may not return; must be done last */
-};
-
#ifdef CONFIG_SMP
static int smt_enabled_cmdline;
@@ -456,13 +450,6 @@ #endif
DBG(" <- setup_system()\n");
}
-static int ppc64_panic_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- ppc_md.panic((char *)ptr); /* May not return */
- return NOTIFY_DONE;
-}
-
#ifdef CONFIG_IRQSTACKS
static void __init irqstack_early_init(void)
{
@@ -517,8 +504,6 @@ static void __init emergency_stack_init(
*/
void __init setup_arch(char **cmdline_p)
{
- extern void do_init_bootmem(void);
-
ppc64_boot_msg(0x12, "Setup Arch");
*cmdline_p = cmd_line;
@@ -535,8 +520,7 @@ void __init setup_arch(char **cmdline_p)
panic_timeout = 180;
if (ppc_md.panic)
- atomic_notifier_chain_register(&panic_notifier_list,
- &ppc64_panic_block);
+ setup_panic();
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
^ permalink raw reply related
* Re: Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-05 4:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <17498.34041.993647.189930@cargo.ozlabs.ibm.com>
On May 4, 2006, at 5:49 PM, Paul Mackerras wrote:
> Kumar Gala writes:
>
>> Please pull from 'for_paulus' branch of
>> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
>
>> --- a/arch/powerpc/kernel/setup_32.c
>> +++ b/arch/powerpc/kernel/setup_32.c
>> @@ -236,6 +236,7 @@ arch_initcall(ppc_init);
>> void __init setup_arch(char **cmdline_p)
>> {
>> extern void do_init_bootmem(void);
>> + extern void setup_panic(void);
>
> Urk.
Yeah didn't care for it either. Will move to "setup.h"
>
>> @@ -285,6 +286,9 @@ #endif
>> /* reboot on panic */
>> panic_timeout = 180;
>>
>> + if (ppc_md.panic)
>> + setup_panic();
>
> Since no 32-bit platform sets ppc_md.panic AFAICS, I guess this
> doesn't need to be pushed into 2.6.17. Please redo with setup_panic
> declared in a header file.
Yeah, this was for 2.6.18. (will do on the header change)
- k
^ permalink raw reply
* Re: kernel debugging
From: David H. Lynch Jr. @ 2006-05-04 9:20 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605030711q69426a59j28db8e38be73f1f0@mail.gmail.com>
Everyone has their own debugging style.
Engineers seem to like hardware debugging tools. I have used some
very fancy debugging hardware, but except for extremely rare instances
it is more work to get setup
and figure out what you are trying to do than inserting some
debugging and rebuilding.
My idea of debugging hardware is a port with an LED on it I can try
to blink.
I also only rarely use software debuggers.
Most of the time when things go off the rails the critical question
for me is Where did things go wrong. Once I know that usually the
problem is obvious and I do nto need dumps of variables or memory.
I also do development across numerous platforms, OS's and languages.
I need debugging tools and techniques that are broadly portable. A
hardware debugging tool might help with board bringup, but it would be
of little use
for web or perl programming. Investing time and capitol in highly
specialized tools or knowledge requires being narrowly focused to get a
worthwhile payback.
Regardless, I think debugging is a sort of religious preference. You
need to know who you are and what you need. Other peoples experience is
useful but should not be determinative.
Steve Iribarne (GMail) wrote:
> Hello.
>
> This is more a general question to see what others do out here. I am
> begining to get sick of printk debugging. I work on two different PPC
> boards. An 860 and 8260.
>
> I want to get some feedback on the best kernel debugger to use. I
> have been looking at three.
>
> 1. kgdb
> 2. kdb
> 3. UML
>
> I am leaning towards kgdb, but before I jump in I thought I'd put this
> out to the best group I could think of linuxppc. Because I am sure
> most of you are using something! :)
>
> Thanks.
>
> -stv
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
^ permalink raw reply
* Re: [PATCH 1/2] PAL: Support of the fixed PHY
From: Vitaly Bordug @ 2006-05-05 0:51 UTC (permalink / raw)
To: Andy Fleming; +Cc: linuxppc-embedded
In-Reply-To: <F785D5DD-4C81-48BE-B63C-FF72E2A648E9@freescale.com>
On Thu, 4 May 2006 19:21:12 -0500
Andy Fleming <afleming@freescale.com> wrote:
> What happened to this patch? It doesn't seem to have been applied to
> any trees. Well, I'm gonna give it a little review now, since I have
> some time.
>
Under final review/updates, gonna to push uptodated shortly...
> On Apr 3, 2006, at 10:26, Vitaly Bordug wrote:
>
> >
> > This makes it possible for HW PHY-less boards to utilize PAL goodies.
> > Generic routines to connect to fixed PHY are provided, as well as
> > ability
> > to specify software callback that fills up link, speed, etc.
> > information
> > into PHY descriptor (the latter feature not tested so far).
> >
> > Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> > ---
>
> [snip]
>
> > +/
> > *---------------------------------------------------------------------
> > --------
> > + * This func is used to create all the necessary stuff, bind
> > + * the fixed phy driver and register all it on the mdio_bus_type.
> > + * speed is either 10 or 100, duplex is boolean.
> > + * number is used to create multiple fixed PHYs, so that several
> > devices can
> > + * utilize them simultaneously.
> > +
> > *---------------------------------------------------------------------
> > --------*/
> > +static int fixed_mdio_register_device(int number, int speed, int
> > duplex)
> > +{
> > + struct mii_bus *new_bus;
> > + struct fixed_info *fixed;
> > + struct phy_device *phydev;
> > + int err = 0;
> > +
> > + struct device* dev = kzalloc(sizeof(struct device), GFP_KERNEL);
> > +
> > + if (NULL == dev)
> > + return -EINVAL;
> > +
> > + new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
> > +
> > + if (NULL == new_bus)
> > + return -ENOMEM;
>
> You don't free dev, here
>
> > +
> > + fixed = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
> > +
> > + if (NULL == fixed) {
> > + kfree(new_bus);
> > + return -ENOMEM;
> > + }
>
> And dev
>
>
> > +
> > + fixed->regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
>
> You don't check for failure for regs's allocation.
>
As to upper notes, OK.
> [snip]
>
> > + /* create phy_device and register it on the mdio bus */
> > + phydev = phy_device_create(new_bus, 0, 0);
> > +
> > + /*
> > + Put the phydev pointer into the fixed pack so that bus read/
> > write code could be able
> > + to access for instance attached netdev. Well it doesn't have to
> > do so, only in case
> > + of utilizing user-specified link-update...
> > + */
> > + fixed->phydev = phydev;
> > +
> > + if(NULL == phydev) {
> > + err = -ENOMEM;
> > + goto bus_register_fail;
> > + }
>
> You're going to need to change this, because phydev isn't guaranteed
> to be NULL in the event of a failure to allocate. it will be ERR_PTR
> (-ENOMEM). I know you changed this in phy_device_create(), but I
> have more on that later. You should do:
>
> if (IS_ERR(phydev)) {
> err = PTR_ERR(-ENOMEM);
> goto bus_register_fail;
> }
>
Assuming IS_ERR will shoot on NULL too, the code is not quite right(see below) :)
But I agree this check is odd - will fix.
> [snip]
>
> > +
> > + return 0;
> > +
> > +bus_register_fail:
> > + kfree(new_bus);
>
> You need to free regs and dev, too
>
>
ok
>
> > diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> > index 459443b..c87f89e 100644
> > --- a/drivers/net/phy/mdio_bus.c
> > +++ b/drivers/net/phy/mdio_bus.c
> > @@ -66,7 +66,7 @@ int mdiobus_register(struct mii_bus *bus
> > phydev = get_phy_device(bus, i);
> >
> > if (IS_ERR(phydev))
> > - return PTR_ERR(phydev);
> > + continue;
>
>
> No. Why'd you change that? Now mdiobus_register doesn't return an
> error if memory runs out. Here's how the system works:
> get_phy_device() can return one of three things:
>
> 1) A pointer to a newly allocated phy_device
> 2) a NULL pointer, indicating that there is no PHY at that address
> (indicated by the bus returning all Fs)
> 3) an error (due to bus read failure, or to memory allocation
> failure, as indicated by PTR_ERR(phydev)
>
> This change has several issues:
> 1) due to the change below, IS_ERR(phydev) is never true
> 2) If you continue, mdiobus_register() will not inform its caller
> that it failed.
>
I am not really stick to this change, but it simply does not work otherwise.
I want the whole bus to be scanned, and the code scans until first fail, and returns error when there's no phy. Hereby, having phy's on 0 and 3 I end up with only 0 registered on bus. So maybe check for NULL and continue, check for err and return... Will inquire and fix - no big deal.
> > diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/
> > phy_device.c
> > index 7da0e3d..0dffecf 100644
> > --- a/drivers/net/phy/phy_device.c
> > +++ b/drivers/net/phy/phy_device.c
> > @@ -46,6 +46,35 @@ static struct phy_driver genphy_driver;
> > extern int mdio_bus_init(void);
> > extern void mdio_bus_exit(void);
> >
> > +struct phy_device* phy_device_create(struct mii_bus *bus, int
> > addr, int phy_id)
> > +{
> > + struct phy_device *dev;
> > + /* We allocate the device, and initialize the
> > + * default values */
> > + dev = kcalloc(1, sizeof(*dev), GFP_KERNEL);
> > +
> > + if (NULL == dev)
> > + return NULL;
>
> Here's the other change which breaks get_phy_device(). Now it
> doesn't return an error when it fails to allocate memory, it returns
> NULL. Which mdiobus_register doesn't interpret as an error (because
> it isn't. Not every PHY address has a device on it).
>
OK, this part definitely needs a bit attention and a rework. So, phy_device_create should return PTR_ERR if it fail to allocate memory, and we need to keep get_phy_device() return as it was, right?
> > +
> > + dev->speed = 0;
> > + dev->duplex = -1;
> > + dev->pause = dev->asym_pause = 0;
> > + dev->link = 1;
> > +
> > + dev->autoneg = AUTONEG_ENABLE;
> > +
> > + dev->addr = addr;
> > + dev->phy_id = phy_id;
> > + dev->bus = bus;
> > +
> > + dev->state = PHY_DOWN;
> > +
> > + spin_lock_init(&dev->lock);
> > +
> > + return dev;
> > +}
> > +EXPORT_SYMBOL(phy_device_create);
>
> Also, as a side note, I'm not completely convinced you need to go
> through this degree of effort to circumvent the PHY Layer's normal
> operation. I think it should be possible to make it simpler. With
> the right implementation, it should even be possible to do really
> "clever" things, like allow users to change the PHY settings with
> ethtool. However, this code exists and works (I'm assuming), and
> that's good enough for now. I'll be glad to have this capability
> next time someone asks me to boot linux on a simulator.
>
I made it as it is not that complex as it seemed at the first sight,
and may be a proving ground to some incoming PAL feature. Also, if there is fixed PHY,
it often does not mean it is really "fixed" - it may be just far too weird to suite into any known form,
but still able to control the link etc.
So, the main aim is to do: if PAL doesn't know PHY, use fixed phy. If you do not want it fixed and wanna to control the link - ok, just implement the link update callback, pass it to emulated PHY, and here we go...
--
Sincerely,
Vitaly
^ permalink raw reply
* Re: Flash map information in device tree.
From: David Woodhouse @ 2006-05-05 0:33 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <1146787262.12254.5.camel@vader.jdub.homelinux.org>
On Thu, 2006-05-04 at 19:01 -0500, Josh Boyer wrote:
> On Fri, 2006-05-05 at 00:34 +0100, David Woodhouse wrote:
> > I'd like to get rid of some of the 'map' drivers in drivers/mtd/maps/
> > and replace them with simple platform devices. On PPC, I'd like to do
> > that with nodes in the device tree, with appropriate properties:
> > - physical address
> > - size
> > - bankwidth
> > - chip probe type (CFI/JEDEC/RAM/ROM/etc)
>
> Hm. How do you deal with NAND, which really isn't any of the above and
> can really depend on things like controllers, etc.
>
> Or was this only for NOR for the time being?
Only NOR. NAND requires a little more than just "where is it?".
--
dwmw2
^ permalink raw reply
* Re: [PATCH 1/2] PAL: Support of the fixed PHY
From: Andy Fleming @ 2006-05-05 0:21 UTC (permalink / raw)
To: Vitaly Bordug; +Cc: linuxppc-embedded
In-Reply-To: <20060403152622.26013.14459.stgit@vitb.ru.mvista.com>
What happened to this patch? It doesn't seem to have been applied to
any trees. Well, I'm gonna give it a little review now, since I have
some time.
On Apr 3, 2006, at 10:26, Vitaly Bordug wrote:
>
> This makes it possible for HW PHY-less boards to utilize PAL goodies.
> Generic routines to connect to fixed PHY are provided, as well as
> ability
> to specify software callback that fills up link, speed, etc.
> information
> into PHY descriptor (the latter feature not tested so far).
>
> Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
> ---
[snip]
> +/
> *---------------------------------------------------------------------
> --------
> + * This func is used to create all the necessary stuff, bind
> + * the fixed phy driver and register all it on the mdio_bus_type.
> + * speed is either 10 or 100, duplex is boolean.
> + * number is used to create multiple fixed PHYs, so that several
> devices can
> + * utilize them simultaneously.
> +
> *---------------------------------------------------------------------
> --------*/
> +static int fixed_mdio_register_device(int number, int speed, int
> duplex)
> +{
> + struct mii_bus *new_bus;
> + struct fixed_info *fixed;
> + struct phy_device *phydev;
> + int err = 0;
> +
> + struct device* dev = kzalloc(sizeof(struct device), GFP_KERNEL);
> +
> + if (NULL == dev)
> + return -EINVAL;
> +
> + new_bus = kzalloc(sizeof(struct mii_bus), GFP_KERNEL);
> +
> + if (NULL == new_bus)
> + return -ENOMEM;
You don't free dev, here
> +
> + fixed = kzalloc(sizeof(struct fixed_info), GFP_KERNEL);
> +
> + if (NULL == fixed) {
> + kfree(new_bus);
> + return -ENOMEM;
> + }
And dev
> +
> + fixed->regs = kzalloc(MII_REGS_NUM*sizeof(int), GFP_KERNEL);
You don't check for failure for regs's allocation.
[snip]
> + /* create phy_device and register it on the mdio bus */
> + phydev = phy_device_create(new_bus, 0, 0);
> +
> + /*
> + Put the phydev pointer into the fixed pack so that bus read/
> write code could be able
> + to access for instance attached netdev. Well it doesn't have to
> do so, only in case
> + of utilizing user-specified link-update...
> + */
> + fixed->phydev = phydev;
> +
> + if(NULL == phydev) {
> + err = -ENOMEM;
> + goto bus_register_fail;
> + }
You're going to need to change this, because phydev isn't guaranteed
to be NULL in the event of a failure to allocate. it will be ERR_PTR
(-ENOMEM). I know you changed this in phy_device_create(), but I
have more on that later. You should do:
if (IS_ERR(phydev)) {
err = PTR_ERR(-ENOMEM);
goto bus_register_fail;
}
[snip]
> +
> + return 0;
> +
> +bus_register_fail:
> + kfree(new_bus);
You need to free regs and dev, too
> diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
> index 459443b..c87f89e 100644
> --- a/drivers/net/phy/mdio_bus.c
> +++ b/drivers/net/phy/mdio_bus.c
> @@ -66,7 +66,7 @@ int mdiobus_register(struct mii_bus *bus
> phydev = get_phy_device(bus, i);
>
> if (IS_ERR(phydev))
> - return PTR_ERR(phydev);
> + continue;
No. Why'd you change that? Now mdiobus_register doesn't return an
error if memory runs out. Here's how the system works:
get_phy_device() can return one of three things:
1) A pointer to a newly allocated phy_device
2) a NULL pointer, indicating that there is no PHY at that address
(indicated by the bus returning all Fs)
3) an error (due to bus read failure, or to memory allocation
failure, as indicated by PTR_ERR(phydev)
This change has several issues:
1) due to the change below, IS_ERR(phydev) is never true
2) If you continue, mdiobus_register() will not inform its caller
that it failed.
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/
> phy_device.c
> index 7da0e3d..0dffecf 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -46,6 +46,35 @@ static struct phy_driver genphy_driver;
> extern int mdio_bus_init(void);
> extern void mdio_bus_exit(void);
>
> +struct phy_device* phy_device_create(struct mii_bus *bus, int
> addr, int phy_id)
> +{
> + struct phy_device *dev;
> + /* We allocate the device, and initialize the
> + * default values */
> + dev = kcalloc(1, sizeof(*dev), GFP_KERNEL);
> +
> + if (NULL == dev)
> + return NULL;
Here's the other change which breaks get_phy_device(). Now it
doesn't return an error when it fails to allocate memory, it returns
NULL. Which mdiobus_register doesn't interpret as an error (because
it isn't. Not every PHY address has a device on it).
> +
> + dev->speed = 0;
> + dev->duplex = -1;
> + dev->pause = dev->asym_pause = 0;
> + dev->link = 1;
> +
> + dev->autoneg = AUTONEG_ENABLE;
> +
> + dev->addr = addr;
> + dev->phy_id = phy_id;
> + dev->bus = bus;
> +
> + dev->state = PHY_DOWN;
> +
> + spin_lock_init(&dev->lock);
> +
> + return dev;
> +}
> +EXPORT_SYMBOL(phy_device_create);
Also, as a side note, I'm not completely convinced you need to go
through this degree of effort to circumvent the PHY Layer's normal
operation. I think it should be possible to make it simpler. With
the right implementation, it should even be possible to do really
"clever" things, like allow users to change the PHY settings with
ethtool. However, this code exists and works (I'm assuming), and
that's good enough for now. I'll be glad to have this capability
next time someone asks me to boot linux on a simulator.
Andy Fleming
^ permalink raw reply
* Re: Flash map information in device tree.
From: Josh Boyer @ 2006-05-05 0:01 UTC (permalink / raw)
To: David Woodhouse; +Cc: linuxppc-dev
In-Reply-To: <1146785683.2885.148.camel@hades.cambridge.redhat.com>
On Fri, 2006-05-05 at 00:34 +0100, David Woodhouse wrote:
> I'd like to get rid of some of the 'map' drivers in drivers/mtd/maps/
> and replace them with simple platform devices. On PPC, I'd like to do
> that with nodes in the device tree, with appropriate properties:
> - physical address
> - size
> - bankwidth
> - chip probe type (CFI/JEDEC/RAM/ROM/etc)
Hm. How do you deal with NAND, which really isn't any of the above and
can really depend on things like controllers, etc.
Or was this only for NOR for the time being?
> - partitioning information
>
> Can we define a format for this so it can be included in the device
> trees which we're presumably going to be generating for the embedded
> boards which are supported by the arch/powerpc kernel?
Platform drivers in general would be a good starting point I think.
Then you can transition those to using the generated flat device tree,
right?
>
> If we can get either an updated u-boot or a boot wrapper which work on
> the Wind River SBC8265 or SBC8560 boards, I might even be able to test
> it myself.
Or if anyone is ambitions and wants to get things working on a bamboo
board... :)
josh
^ permalink raw reply
* Hang in die() when using NMI soft-reset
From: David Wilder @ 2006-05-05 0:25 UTC (permalink / raw)
To: linuxppc-dev
I am debugging problem found in during kdump testing on a power 5 system
2.6.16. Maybe someone has some ideas?
I am generating an NMI from the firmware. Each cpu responds to the NMI
and calls system_reset_exception() ->
die()->show_regs()->show_instructions(). Sometimes the cpu will hang
in show_instructions(). Since the cpu is holding the die_lock() any
cpus that have not already run die() waits on the lock forever. In
show_instructions() a call is made to might_sleep(). The only reason I
can see for it to sleep would be if it takes page or SLB fault?
I have not yet tested other fault paths that call die for the problem.
Oops: System Reset, sig: 6 [#1]
SMP NR_CPUS=128 NUMA PSERIES LPAR
Modules linked in: crasher ipv6 apparmor aamatch_pcre loop dm_mod ide_cd
cdrom e1000 sg ipr firmware_class pdc202xx_new sd_mod scsi_mod
NIP: C000000000028AC0 LR: C000000000028AA0 CTR: 800000000014DCD0
REGS: c0000000e84a3250 TRAP: 0100 Tainted: G U
(2.6.16.9-20060423154214-ppc64)
MSR: 8000000000089032 <EE,ME,IR,DR> CR: 24448428 XER: 00000000
TASK = c00000000f854340[2747] 'hald-addon-stor' THREAD: c0000000e84a0000
CPU: 0
GPR00: 0000000000000002 C0000000E84A34D0 C00000000062ECE8 0000000000000080
GPR04: 0000000000000080 0000000000000080 8000000000C24393 0000000000000002
GPR08: 0000000000000004 C000000000633E88 C000000000634090 000000B1044EAA9E
GPR12: 0000000000004000 C000000000492E80 0000000010000000 0000000010000000
GPR16: 0000000010000000 0000000010002EF0 0000000010000000 0000000010000000
GPR20: 00000000FFF3E15C 0000000000000800 00000000FFF3E1C4 0000000000000001
GPR24: C0000000EA4E8C18 C0000000EA4E8CC0 C0000000E6886380 C0000000EA4E8CC0
GPR28: C0000000EA4E8C00 C0000000EA4E8C00 0000000000000001 0000000000000003
NIP [C000000000028AC0] .smp_call_function+0xd8/0x1c8
LR [C000000000028AA0] .smp_call_function+0xb8/0x1c8
Call Trace:
[C0000000E84A34D0] [C000000000028AA0] .smp_call_function+0xb8/0x1c8
(unreliable)
[C0000000E84A3570] [C0000000000CA00C] .invalidate_bdev+0x30/0x64
[C0000000E84A3600] [C0000000000EAAF8] .__invalidate_device+0x5c/0x80
[C0000000E84A3690] [C0000000000D231C] .check_disk_change+0x68/0xec
[C0000000E84A3720] [D00000000032DBF0] .cdrom_open+0xb14/0xb80 [cdrom]
[C0000000E84A3940] [D0000000002D1700] .idecd_open+0x128/0x19c [ide_cd]
[C0000000E84A39E0] [C0000000000D2940] .do_open+0x11c/0x5c4
[C0000000E84A3AA0] [C0000000000D30B0] .blkdev_open+0x38/0x88
[C0000000E84A3B30] [C0000000000C47D8] .__dentry_open+0x160/0x300
[C0000000E84A3BE0] [C0000000000C4AEC] .do_filp_open+0x50/0x70
[C0000000E84A3D00] [C0000000000C4B80] .do_sys_open+0x74/0x12c
[C0000000E84A3DB0] [C0000000001017A0] .compat_sys_open+0x24/0x38
[C0000000E84A3E30] [C00000000000871C] syscall_exit+0x0/0x40
Instruction dump: pc=0xc000000000028a90
#1 pc = 0xc000000000028a90 i=0
--
David Wilder
IBM Linux Technology Center
Beaverton, Oregon, USA
dwilder@us.ibm.com
(503)578-3789
^ permalink raw reply
* Flash map information in device tree.
From: David Woodhouse @ 2006-05-04 23:34 UTC (permalink / raw)
To: linuxppc-dev
I'd like to get rid of some of the 'map' drivers in drivers/mtd/maps/
and replace them with simple platform devices. On PPC, I'd like to do
that with nodes in the device tree, with appropriate properties:
- physical address
- size
- bankwidth
- chip probe type (CFI/JEDEC/RAM/ROM/etc)
- partitioning information
Can we define a format for this so it can be included in the device
trees which we're presumably going to be generating for the embedded
boards which are supported by the arch/powerpc kernel?
If we can get either an updated u-boot or a boot wrapper which work on
the Wind River SBC8265 or SBC8560 boards, I might even be able to test
it myself.
--
dwmw2
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch of powerpc
From: Paul Mackerras @ 2006-05-04 22:49 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0605041622180.3700-100000@gate.crashing.org>
Kumar Gala writes:
> Please pull from 'for_paulus' branch of
> master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
> --- a/arch/powerpc/kernel/setup_32.c
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -236,6 +236,7 @@ arch_initcall(ppc_init);
> void __init setup_arch(char **cmdline_p)
> {
> extern void do_init_bootmem(void);
> + extern void setup_panic(void);
Urk.
> @@ -285,6 +286,9 @@ #endif
> /* reboot on panic */
> panic_timeout = 180;
>
> + if (ppc_md.panic)
> + setup_panic();
Since no 32-bit platform sets ppc_md.panic AFAICS, I guess this
doesn't need to be pushed into 2.6.17. Please redo with setup_panic
declared in a header file.
Paul.
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch of powerpc
From: Segher Boessenkool @ 2006-05-04 22:36 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <55C365AA-2BA4-406C-8518-616F8182FAE5@kernel.crashing.org>
>>> void __init setup_arch(char **cmdline_p)
>>> {
>>> extern void do_init_bootmem(void);
>>> + extern void setup_panic(void);
>>
>> Can those two go into a header file please?
>
> any suggestions on which header?
The new one should just go into arch/powerpc/kernel/setup.h;
the bootmem thing could go there as well perhaps.
Segher
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-04 22:10 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <6B4D81B3-ECB5-4492-B3EE-16EAAEBF1405@kernel.crashing.org>
On May 4, 2006, at 5:09 PM, Segher Boessenkool wrote:
> Hi Kumar,
>
>> +static int ppc_panic_event(struct notifier_block *this,
>> + unsigned long event, void *ptr)
>> +{
>> + ppc_md.panic((char *)ptr); /* May not return */
>> + return NOTIFY_DONE;
>> +}
>
> Lose the redundant pointer cast while you're there please?
>
>> void __init setup_arch(char **cmdline_p)
>> {
>> extern void do_init_bootmem(void);
>> + extern void setup_panic(void);
>
> Can those two go into a header file please?
any suggestions on which header?
^ permalink raw reply
* Re: Please pull from 'for_paulus' branch of powerpc
From: Segher Boessenkool @ 2006-05-04 22:09 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <Pine.LNX.4.44.0605041622180.3700-100000@gate.crashing.org>
Hi Kumar,
> +static int ppc_panic_event(struct notifier_block *this,
> + unsigned long event, void *ptr)
> +{
> + ppc_md.panic((char *)ptr); /* May not return */
> + return NOTIFY_DONE;
> +}
Lose the redundant pointer cast while you're there please?
> void __init setup_arch(char **cmdline_p)
> {
> extern void do_init_bootmem(void);
> + extern void setup_panic(void);
Can those two go into a header file please?
Segher
^ permalink raw reply
* Re: [openib-general] [PATCH 07/16] ehca: interrupt handling routines
From: Roland Dreier @ 2006-05-04 21:29 UTC (permalink / raw)
To: Heiko J Schick
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Hoang-Nam Nguyen, Marcus Eder
In-Reply-To: <4450A196.2050901@de.ibm.com>
> +void ehca_queue_comp_task(struct ehca_comp_pool *pool, struct ehca_cq *__cq)
> +{
> + int cpu;
> + int cpu_id;
> + struct ehca_cpu_comp_task *cct;
> + unsigned long flags_cct;
> + unsigned long flags_cq;
> +
> + cpu = get_cpu();
> + cpu_id = find_next_online_cpu(pool);
> +
> + EDEB_EN(7, "pool=%p cq=%p cq_nr=%x CPU=%x:%x:%x:%x",
> + pool, __cq, __cq->cq_number,
> + cpu, cpu_id, num_online_cpus(), num_possible_cpus());
> +
> + BUG_ON(!cpu_online(cpu_id));
> +
> + cct = per_cpu_ptr(pool->cpu_comp_tasks, cpu_id);
> +
> + spin_lock_irqsave(&cct->task_lock, flags_cct);
> + spin_lock_irqsave(&__cq->task_lock, flags_cq);
> +
> + if (__cq->nr_callbacks == 0) {
> + __cq->nr_callbacks++;
> + list_add_tail(&__cq->entry, &cct->cq_list);
> + wake_up(&cct->wait_queue);
> + }
> + else
> + __cq->nr_callbacks++;
> +
> + spin_unlock_irqrestore(&__cq->task_lock, flags_cq);
> + spin_unlock_irqrestore(&cct->task_lock, flags_cct);
> +
> + put_cpu();
> +
> + EDEB_EX(7, "cct=%p", cct);
> +
> + return;
> +}
I never read the ehca completion event handling code very carefully
until now. But I was motivated by Shirley's work on IPoIB to take a
closer look.
It seems that you are deferring completion event dispatch into threads
spread across all the CPUs. This seems like a very strange thing to
me -- you are adding latency and possibly causing cacheline pingpong.
It may help throughput in some cases to spread the work across
multiple CPUs but it seems strange to me to do this in the low-level
driver. My intuition would be that it would be better to do this in
the higher levels, and leave open the possibility for protocols that
want the lowest possible latency to be called directly from the
interrupt handler.
What was the thinking that led to this design?
- R.
^ permalink raw reply
* Please pull from 'for_paulus' branch of powerpc
From: Kumar Gala @ 2006-05-04 21:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, linux-kernel
Please pull from 'for_paulus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git
to receive the following updates:
arch/powerpc/kernel/setup-common.c | 17 +++++++++++++++++
arch/powerpc/kernel/setup_32.c | 4 ++++
arch/powerpc/kernel/setup_64.c | 17 ++---------------
3 files changed, 23 insertions(+), 15 deletions(-)
Kumar Gala:
powerpc: provide ppc_md.panic() for both ppc32 & ppc64
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 684ab1d..7a6a883 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -524,3 +524,20 @@ int check_legacy_ioport(unsigned long ba
return ppc_md.check_legacy_ioport(base_port);
}
EXPORT_SYMBOL(check_legacy_ioport);
+
+static int ppc_panic_event(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ ppc_md.panic((char *)ptr); /* May not return */
+ return NOTIFY_DONE;
+}
+
+static struct notifier_block ppc_panic_block = {
+ .notifier_call = ppc_panic_event,
+ .priority = INT_MIN /* may not return; must be done last */
+};
+
+void __init setup_panic(void)
+{
+ atomic_notifier_chain_register(&panic_notifier_list, &ppc_panic_block);
+}
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 69ac257..9d55234 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -236,6 +236,7 @@ arch_initcall(ppc_init);
void __init setup_arch(char **cmdline_p)
{
extern void do_init_bootmem(void);
+ extern void setup_panic(void);
/* so udelay does something sensible, assume <= 1000 bogomips */
loops_per_jiffy = 500000000 / HZ;
@@ -285,6 +286,9 @@ #endif
/* reboot on panic */
panic_timeout = 180;
+ if (ppc_md.panic)
+ setup_panic();
+
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
init_mm.end_data = (unsigned long) _edata;
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 4467c49..ff6726f 100644
--- a/arch/powerpc/kernel/setup_64.c
+++ b/arch/powerpc/kernel/setup_64.c
@@ -100,12 +100,6 @@ unsigned long SYSRQ_KEY;
#endif /* CONFIG_MAGIC_SYSRQ */
-static int ppc64_panic_event(struct notifier_block *, unsigned long, void *);
-static struct notifier_block ppc64_panic_block = {
- .notifier_call = ppc64_panic_event,
- .priority = INT_MIN /* may not return; must be done last */
-};
-
#ifdef CONFIG_SMP
static int smt_enabled_cmdline;
@@ -456,13 +450,6 @@ #endif
DBG(" <- setup_system()\n");
}
-static int ppc64_panic_event(struct notifier_block *this,
- unsigned long event, void *ptr)
-{
- ppc_md.panic((char *)ptr); /* May not return */
- return NOTIFY_DONE;
-}
-
#ifdef CONFIG_IRQSTACKS
static void __init irqstack_early_init(void)
{
@@ -518,6 +505,7 @@ static void __init emergency_stack_init(
void __init setup_arch(char **cmdline_p)
{
extern void do_init_bootmem(void);
+ extern void setup_panic(void);
ppc64_boot_msg(0x12, "Setup Arch");
@@ -535,8 +523,7 @@ void __init setup_arch(char **cmdline_p)
panic_timeout = 180;
if (ppc_md.panic)
- atomic_notifier_chain_register(&panic_notifier_list,
- &ppc64_panic_block);
+ setup_panic();
init_mm.start_code = PAGE_OFFSET;
init_mm.end_code = (unsigned long) _etext;
^ permalink raw reply related
* Re: kernel debugging
From: Mark Chambers @ 2006-05-04 20:13 UTC (permalink / raw)
To: Steve Iribarne (GMail); +Cc: linuxppc-embedded
In-Reply-To: <b4b98b690605041251s40f88731i1edfdfb324da38b4@mail.gmail.com>
>> >
>> > This is more a general question to see what others do out here. I am
>> > begining to get sick of printk debugging. I work on two different PPC
>> > boards. An 860 and 8260.
>> >
>> > I want to get some feedback on the best kernel debugger to use. I
>> > have been looking at three.
>> >
>> > 1. kgdb
>> > 2. kdb
>> > 3. UML
>> >
For the 860 you can purchase a hardware debugger from www.denx.de for
50 Euros. For the 8260 you must buy the more expensive BDI2000, but
that is Freescale's fault. But the look and feel of BDI2000 is the same as
BDI4GDB, just faster, so you can decide whether it's worth the money for
you.
When you say 'kgdb' you imply 'gdb' which is the standard GNU-world
debugger. kgdb is a means for letting a kernel communicate with a PC based
(or equivalent) gdb and is an alternative to a hardware debugger. Also,
check out ddd, a front end for gdb.
IMHO, these serial debugging ports on PPC are the greatest thing since
sliced
bread and it would be foolish not to take advantage of them.
Mark C.
^ permalink raw reply
* Re: Moving from 2.4 to 2.6 kernel
From: Grant Likely @ 2006-05-04 20:04 UTC (permalink / raw)
To: Chris Dumoulin; +Cc: linuxppc-embedded
In-Reply-To: <445A534D.8090800@ics-ltd.com>
On 5/4/06, Chris Dumoulin <cdumoulin@ics-ltd.com> wrote:
> I'm looking into getting a BDI 2000 so I can start stepping through and
> see what is going on.
>
> I looked at the ML300 and V2Pro code in the arch/ppc/platforms/4xx
> folder, but I did not use any of that in my code. It looks like this is
> intended to be used with the BSP that is generated by Xilinx Platform
> Studio. I've tried generating the BSP this way, but the generated code
> is obviously not a complete patch to port Linux to your hardware, and I
> figure that by the time I figure out what I do/don't have to add, I
> might as well write the whole thing by myself. Have you had success
> integrating the automatically generated BSP from Xilinx Platform Studio?
No; the stuff in 2.6 is not integrated w/ platform studio. (only 2.4
is). However, you do need to extract the xparameters.h file from the
platform studio BSP. You can generate a Linux BSP w/o actually
telling it where your Linux tree is. Once its generated; pull out
xparameters.h and drop it into arch/ppc/platforms/4xx/xparameters/ in
your source tree. Note: it's important that you generate a LINUX BSP;
not a 'standalone' bsp. If you don't, then you'll be missing a bunch
of #defines.
Let me say that once more for clarity: The only file you need from
platform studio is the generated xparameters.h
This will give you at the very least a serial port driver. Once your
booting with that, you can focus on other device drivers.
Trust me; this is the path of far less pain.
Cheers,
g.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
(403) 399-0195
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox