* Re: BDI2000 and MPC8272
From: Artur Barkhudaryan @ 2006-08-15 9:41 UTC (permalink / raw)
To: Yanjun Luo; +Cc: linuxppc-embedded
In-Reply-To: <002c01c6c042$19445140$9e00a8c0@embed>
Hello,
> Of course you should get it from www.abatron.ch, or their distributors.
> I think contact the one who sold the BDI2000 to you is a good idea.
I will try to contact them directly, thanks for your time.
Best regards,
Artur Barkhudaryan
^ permalink raw reply
* eldk4.0 ppc_85xx-gdb failure while debugging with BDI2000
From: emre kara @ 2006-08-15 8:41 UTC (permalink / raw)
To: linuxppc-embedded
Dear All;
Is there any one use BDI2000 ppc_85xx-gdb (coming with
ELDK4.0 dist). Please examine the log below.
Target is waiting in start_kernel func.
ppc_85xx-gdb vmlinux
......
......
(gdb) target remote 192.168.101.101:2001
Remote debugging using 192.168.101.101:2001
0x00000000 in ?? ()
(gdb) q
gdb can not display correct addr and debug anything.
but at this state, older version toolchain (eldk3.1)
is working properly.
Second problem, I have check denx web site for an gdb
update and found
gdb-ppc_85xx-6.3.0.0-1.21_3.ppc.rpm,but instalation
fails with the error below.
-----------------------------------------
ppc_85xx-rpm -U gdb-ppc_85xx-6.3.0.0-1.21_3.ppc.rpm
error: Failed dependencies:
info-ppc_85xx is needed by
gdb-ppc_85xx-6.3.0.0-1.21_3.ppc
------------------------------------------
Here is my bdi configuration file:
--------------------------------------------------
;bdiGDB configuration file for MPC8540ADS
;----------------------------------------
[INIT]
WM32 0x000000f0 0x00000000 ;invalidate page table
base
[TARGET]
CPUTYPE 8540 ;the CPU type
JTAGCLOCK 0 ;use 16 MHz JTAG clock
STARTUP STOP 100 ;halt core while HRESET is
asserted
BREAKMODE SOFT ;SOFT or HARD, HARD uses PPC
hardware breakpoint
STEPMODE HWBP ;JTAG or HWBP, HWBP uses a hardware
breakpoint
MMU XLAT; for kernel debug
PTBASE 0xf0;for kernel debug
WAKEUP 500 ;give reset time to complete
POWERUP 5000 ;start delay after power-up detected
in ms
[HOST]
PROMPT 8540_KRNL>
[REGS]
FILE $reg8560.def
How can I solve this problems?
Thanks.
Emre
___________________________________________________________
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine
http://uk.docs.yahoo.com/nowyoucan.html
^ permalink raw reply
* Re: BDI2000 and MPC8272
From: Yanjun Luo @ 2006-08-15 8:09 UTC (permalink / raw)
To: Artur Barkhudaryan; +Cc: linuxppc-embedded
In-Reply-To: <1005941084.20060815124945@epygiarm.am>
Hi,
> Umm, no message, it does not understand any of the CPU types
> PPC600/PPC700/MPC8200.
No message? I remember it should display some message that
doesn't support the current CPU.
> I think so... Do you happen to know where one can obtain new firmware
> for BDI2000 ?
Of course you should get it from www.abatron.ch, or their distributors.
I think contact the one who sold the BDI2000 to you is a good idea.
Regards,
Yanjun Luo.
^ permalink raw reply
* Re: BDI2000 and MPC8272
From: Artur Barkhudaryan @ 2006-08-15 7:49 UTC (permalink / raw)
To: Yanjun Luo; +Cc: linuxppc-embedded
In-Reply-To: <002201c6c03d$368769e0$9e00a8c0@embed>
> Hi Artur,
Hello,
>> It does not seem to have support for MPC8272 and I was not able to
>> find any information about how to enable that. I guess I need new
>> firmware, right ? How can I obtain that and where ?
> What message do you see when BDI2000 connect to the board?
Umm, no message, it does not understand any of the CPU types
PPC600/PPC700/MPC8200.
> Maybe you should update your firmware of BDI2000.
I think so... Do you happen to know where one can obtain new firmware
for BDI2000 ?
> Regards,
> Yanjun Luo.
Thanks,
Artur Barkhudaryan
^ permalink raw reply
* Re: [PATCH 1/7] ehea: interface to network stack
From: Heiko Carstens @ 2006-08-15 7:39 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel,
Thomas Klein, linux-ppc, Christoph Raisch, Marcus Eder
In-Reply-To: <44E0A4CC.4090705@de.ibm.com>
> +int __init ehea_module_init(void)
> +{
> + int ret = -EINVAL;
> +
> + EDEB_EN(7, "");
> +
> + printk(KERN_INFO "IBM eHEA Ethernet Device Driver (Release %s)\n",
> + DRV_VERSION);
> +
> +
> + ret = ibmebus_register_driver(&ehea_driver);
> + if (ret) {
> + EDEB_ERR(4, "Failed registering eHEA device driver on ebus");
> + return -EINVAL;
> + }
> +
> + EDEB_EX(7, "");
> + return 0;
> +}
Function should be static and could be shortened to the single line
return ibmebus_register_driver(&ehea_driver);
, I guess :)
^ permalink raw reply
* Re: BDI2000 and MPC8272
From: Yanjun Luo @ 2006-08-15 7:34 UTC (permalink / raw)
To: Artur Barkhudaryan, linuxppc-embedded
In-Reply-To: <824771033.20060815113555@epygiarm.am>
Hi Artur,
> It does not seem to have support for MPC8272 and I was not able to
> find any information about how to enable that. I guess I need new
> firmware, right ? How can I obtain that and where ?
What message do you see when BDI2000 connect to the board?
Maybe you should update your firmware of BDI2000.
Regards,
Yanjun Luo.
^ permalink raw reply
* BDI2000 and MPC8272
From: Artur Barkhudaryan @ 2006-08-15 6:35 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I am trying to use a BDI2000 debugger for a custom MPC8272 board. The
debugger reports support for MPC8xx processors and the following
information
BDI Type : BDI2000 Rev.C
Loader : V1.05
Firmware : V1.10
Logic : V1.02
It does not seem to have support for MPC8272 and I was not able to
find any information about how to enable that. I guess I need new
firmware, right ? How can I obtain that and where ?
I know that this is probably not the best place to ask this question,
but I was unable to find any answer anywhere else...
Thanks a lot,
Artur Barkhudaryan
^ permalink raw reply
* Re: ehea debug output discussion
From: Paul Mackerras @ 2006-08-15 5:10 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, roland, netdev, Thomas Klein,
linux-ppc, Christoph Raisch, Anton Blanchard, Marcus Eder
In-Reply-To: <44E06EDA.6040404@de.ibm.com>
Jan-Bernd Themann writes:
> The outcome of some internal discussions was that it is not acceptable for
> our enterprise users of this type of driver on this target system to need a
> recompile / reload of the driver for error analysis, so we need a mechanism
> that allows us to switch on / off debug output at runtime. Therefore, we'd
> introduce a stripped down version of EDEB.
This is precisely what kprobes is for. There is no need for
EDEB-style debug code in the source given that kprobes gives you the
ability to add logging in at (almost) arbitrary points at runtime. In
fact kprobes is more powerful because you don't have to specify the
set of points of interest when the kernel is built--you can do it
later, at the time of debugging.
Please look into providing a kprobes module and/or a systemtap script
for the debugging points you want rather than cluttering up the source
code with EDEB statements.
Paul.
^ permalink raw reply
* [PATCH] powerpc: Instrument Hypervisor Calls
From: Dave Boutcher @ 2006-08-15 3:32 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060814232144.GG3213@w-mikek2.ibm.com>
On Mon, 14 Aug 2006 16:21:44 -0700, Mike Kravetz <kravetz@us.ibm.com> said:
> Here is an updated version of the patch to instrument hypervisor
> calls. In this version, all statistic updates are performed in
> assembly code. Statistics are made available via debugfs.
> Instrumentation is enabled via a config option and there is zero
> cost if not enabled.
...
> +#define HCALL_INST_POSTCALL \
> + /* get time and PURR snapshots after hcall */ \
> + mftb r7; /* timebase after */ \
if you just add a "mr r8,r7" here you will get consistent
behaviour (either TB and PURR if PURR is supported, or TB
everywhere.) The processor will pretty much optimize that
away if the FTR section is not no-op-ed.
> +BEGIN_FTR_SECTION; \
> + mfspr r8,SPRN_PURR; /* PURR after */ \
> +END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
Dave B
^ permalink raw reply
* RE: PowerPC paxtest results w/ gcc-4.1
From: Paul Mackerras @ 2006-08-15 3:59 UTC (permalink / raw)
To: matt; +Cc: 'Albert Cahalan', linuxppc-dev, debian-powerpc
In-Reply-To: <000301c6bf97$e9151e00$99dfdfdf@bakuhatsu.net>
Matt Sealey writes:
> Book I compatible PowerPC's have had a "no-executable" bit in
> the page protection flags since the dark ages.. see page 7-38
> and 7-39 of the 'Programming Environments Manual for 32-Bit
> Microprocessors'.. this document predates even the G3.
What are you referring to? I have a copy of the PEM from pre-G3 days,
and a copy that I downloaded just now, and neither of them have an N
bit in the PTE (and yes I just looked carefully through pages 7-38 and
7-39).
There is an N bit in the segment register format, and that's what
Albert is using.
> As far as the documentation goes, you can make the page
> readable and writable to the LSU, but the N bit causes the
> instruction fetch to cause a machine check. That's pretty
> "not-executable" to me at least :)
A machine check is nasty, because it may not be recoverable...
Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Stephen Rothwell @ 2006-08-15 3:12 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060815023224.GA3622@monkey.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 692 bytes --]
On Mon, 14 Aug 2006 19:32:24 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
>
> My intention was to detect the presence of PURR in the display (debugfs)
> code. If there is no PURR, then no PURR values are displayed. My thought
> is that it doesn't matter what values are in the field if we don't display
> them.
>
> Unfortunately, I left that bit of code out of the patch.
>
> How does that sound? Suppose I can also put all the 'calculate PURR delta'
> code in the FTR_SECTION to save a few cycles.
That sounds good (as long as you also suppress the display).
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-08-15 2:34 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <44E12B03.6020503@am.sony.com>
On Mon, Aug 14, 2006 at 07:01:39PM -0700, Geoff Levand wrote:
> I want to hook my instrumentation into this config option also, but my
> platform dosn't have PURR, so I would like you to remove the mention
> of '(based on PURR)' in the description of the option. This way we
> can have a generic 'Hypervisor call instrumentation' option for users,
> on whatever platform they are using.
>
> Does it make sense?
Makes sense. No problem. I'll include this update in a revised edition
of the patch.
Thanks,
--
Mike
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-08-15 2:32 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060815110319.5f34417a.sfr@canb.auug.org.au>
On Tue, Aug 15, 2006 at 11:03:19AM +1000, Stephen Rothwell wrote:
> On Mon, 14 Aug 2006 16:21:44 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
> > +#define HCALL_INST_POSTCALL \
> > + /* get time and PURR snapshots after hcall */ \
> > + mftb r7; /* timebase after */ \
> > +BEGIN_FTR_SECTION; \
> > + mfspr r8,SPRN_PURR; /* PURR after */ \
> > +END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
> > + \
> > + /* calculate time and PURR deltas for call */ \
> > + ld r5,STK_PARM(r5)(r1); /* timebase before */ \
> > + subf r5,r5,r7; \
> > + ld r6,STK_PARM(r6)(r1); /* PURR before */ \
> > + subf r6,r6,r8; \
>
> But here, if we have no PURR we produce random numbers. Maybe you should
> reuse the TB value so the values reported may make some sense.
Good catch!
My intention was to detect the presence of PURR in the display (debugfs)
code. If there is no PURR, then no PURR values are displayed. My thought
is that it doesn't matter what values are in the field if we don't display
them.
Unfortunately, I left that bit of code out of the patch.
How does that sound? Suppose I can also put all the 'calculate PURR delta'
code in the FTR_SECTION to save a few cycles.
--
Mike
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Geoff Levand @ 2006-08-15 2:01 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060814234146.GA17027@w-mikek2.ibm.com>
Mike Kravetz wrote:
> On Mon, Aug 14, 2006 at 04:35:12PM -0700, Geoff Levand wrote:
>> Mike Kravetz wrote:
>> > +config HCALL_STATS
>> > + bool "Hypervisor call instrumentation"
>> > + depends on PPC_PSERIES && DEBUG_FS
>> > + help
>> > + Adds code to keep track of the number of hypervisor calls made
> and
>> > + the amount of time spent in hypervisor calls: both wall time
> (based
>> > + on time base) and cpu time (based on PURR). A directory named
>> > + hcall_inst is added at the root of the debugfs filesystem.
>>
>> Could we keep this more generic and not mention platform specific
>> things like PURR?
>
> Not sure if I follow. PURR will be used/displayed if available. Time
> based statistics will always be available.
>
> I can change the description to make this clear. Or, are you asking
> that this not be mentioned at all? Based on previous discussions, I
> added the ability to display both wall and cpu time if available.
I want to hook my instrumentation into this config option also, but my
platform dosn't have PURR, so I would like you to remove the mention
of '(based on PURR)' in the description of the option. This way we
can have a generic 'Hypervisor call instrumentation' option for users,
on whatever platform they are using.
Does it make sense?
-Geoff
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Stephen Rothwell @ 2006-08-15 1:03 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060814232144.GG3213@w-mikek2.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2081 bytes --]
On Mon, 14 Aug 2006 16:21:44 -0700 Mike Kravetz <kravetz@us.ibm.com> wrote:
>
> diff -Naupr powerpc2/arch/powerpc/platforms/pseries/hvCall.S powerpc2.work/arch/powerpc/platforms/pseries/hvCall.S
> --- powerpc2/arch/powerpc/platforms/pseries/hvCall.S 2006-08-14 18:00:55.000000000 +0000
> +++ powerpc2.work/arch/powerpc/platforms/pseries/hvCall.S 2006-08-14 22:17:04.000000000 +0000
> @@ -10,9 +10,66 @@
> #include <asm/hvcall.h>
> #include <asm/processor.h>
> #include <asm/ppc_asm.h>
> +#include <asm/asm-offsets.h>
>
> #define STK_PARM(i) (48 + ((i)-3)*8)
>
> +#ifdef CONFIG_HCALL_STATS
> +/*
> + * precall must preserve all registers. use unused STK_PARM()
> + * areas to save snapshots and opcode.
> + */
> +#define HCALL_INST_PRECALL \
> + std r3,STK_PARM(r3)(r1); /* save opcode */ \
> + mftb r3; /* get timebase and */ \
> + std r3,STK_PARM(r5)(r1); /* save for later */ \
> +BEGIN_FTR_SECTION; \
> + mfspr r3,SPRN_PURR; /* get PURR and */ \
> +END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
> + std r3,STK_PARM(r6)(r1); /* save for later */ \
So if we have no PURR, we use the TB value (this is fine)
> + ld r3,STK_PARM(r3)(r1); /* opcode back in r3 */
> +
> +/*
> + * postcall is performed immediately before function return which
> + * allows liberal use of volital registers.
> + */
> +#define HCALL_INST_POSTCALL \
> + /* get time and PURR snapshots after hcall */ \
> + mftb r7; /* timebase after */ \
> +BEGIN_FTR_SECTION; \
> + mfspr r8,SPRN_PURR; /* PURR after */ \
> +END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
> + \
> + /* calculate time and PURR deltas for call */ \
> + ld r5,STK_PARM(r5)(r1); /* timebase before */ \
> + subf r5,r5,r7; \
> + ld r6,STK_PARM(r6)(r1); /* PURR before */ \
> + subf r6,r6,r8; \
But here, if we have no PURR we produce random numbers. Maybe you should
reuse the TB value so the values reported may make some sense.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Kernel boot-up issue after enabling FCC in MPC8560
From: Junita @ 2006-08-14 23:47 UTC (permalink / raw)
To: linuxppc-embedded
Hello all,
I'm currently bringing up the FCC port in our MPC8560 based custom board
which has one TSEC port and another FCC port. We use u-boot-1.1.4 as
bootloader, where we have enabled FCC3 also.
When I downlaod the kernel and filesystem images through FCC system
boots-up to the prompt.
Sametime , while I download the through TSEC port, kernel hangs at a
strange point i.e before "Freeing the initrd memory".
Any help would be greatly appreciated.
Please find the screen-dump below.
Thanks,
Junita
########################################################################
In: serial
Out: serial
Err: serial
Net: TSEC0, FCC3 ETHERNET
Hit any key to stop autoboot: 0
RMCG8700_8560=> tftp 2000000 mpc8560/fcc/uImage
Speed: 1000, full duplex
Using TSEC0 device
TFTP from server 192.168.201.11; our IP address is 192.168.201.191
Filename 'mpc8560/fcc/uImage'.
Load address: 0x2000000
Loading: #################################################################
#################################################################
#################################################################
#
done
Bytes transferred = 998700 (f3d2c hex)
RMCG8700_8560=> tftp 3000000 mpc8560/fcc/ramdisk.gz
Speed: 1000, full duplex
Using TSEC0 device
TFTP from server 192.168.201.11; our IP address is 192.168.201.191
Filename 'mpc8560/fcc/ramdisk.gz'.
Load address: 0x3000000
Loading: #################################################################
#################################################################
#################################################################
#################################################################
#################################################################
######################################################
done
Bytes transferred = 1935938 (1d8a42 hex)
RMCG8700_8560=> bootm 2000000 3000000
## Booting image at 02000000 ...
Image Name: Linux-2.6.14
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 998636 Bytes = 975.2 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 03000000 ...
Image Name: GDA MPC8560
Image Type: PowerPC Linux RAMDisk Image (gzip compressed)
Data Size: 1935874 Bytes = 1.8 MB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Loading Ramdisk to 0fdc4000, end 0ff9ca02 ... OK
Memory CAM mapping: CAM0=256Mb, CAM1=0Mb, CAM2=0Mb residual: 0Mb
Linux version 2.6.14 (root@crater.gdatech.com) (gcc version 3.3.3 (DENX
ELDK 3.6Built 1 zonelists
Kernel command line:
OpenPIC Version 1.2 (1 CPUs and 60 IRQ sources) at fcf7d000
PID hash table entries: 2048 (order: 11, 32768 bytes)
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 255360k available (1740k kernel code, 448k data, 116k init, 0k
highmem)
Mount-cache hash table entries: 512
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
=====
This message contains information from GDA Technologies Inc and
affiliates, and is intended for the sole use of the individual and
entity to whom it is addressed. It may contain information, including
any attachments, that is privileged, confidential and exempt from
disclosure under applicable law. If you are not the intended addressee,
nor authorized to receive for the intended addressee, you are hereby
notified that you may not use, copy, disclose or distribute to anyone
the message or any information contained in the message. If you have
received this electronic transmission in error, please notify the sender
immediately by a "reply to sender only" message and destroy all
electronic and hard copies of the communication, including attachments.
====
^ permalink raw reply
* Re: [PATCH 4/6] ehea: header files
From: Michael Ellerman @ 2006-08-15 0:08 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44E07267.7070007@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]
On Mon, 2006-08-14 at 14:53 +0200, Jan-Bernd Themann wrote:
> Michael Ellerman wrote:
> >> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31 16:00:00.000000000 -0800
> >> +++ kernel/drivers/net/ehea/ehea.h 2006-08-08 23:59:39.927452928 -0700
> >> +
> >> +#define EHEA_PAGESHIFT 12
> >> +#define EHEA_PAGESIZE 4096UL
> >> +#define EHEA_CACHE_LINE 128
> >
> > This looks like a very bad idea, what happens if you're running on a
> > machine with 64K pages?
> >
>
> The EHEA_PAGESIZE define is needed for queue management to hardware side.
You mean the eHEA has its own concept of page size? Separate from the
page size used by the MMU?
> >> +/*
> >> + * h_galpa:
> >> + * for pSeries this is a 64bit memory address where
> >> + * I/O memory is mapped into CPU address space
> >> + */
> >> +
> >> +struct h_galpa {
> >> + u64 fw_handle;
> >> +};
> >
> > What is a h_galpa? And why does it need a struct if it's just a u64?
> >
>
> The eHEA chip is not PCI attached but directly connected to a proprietary
> bus. Currently, we can access it by a simple 64 bit address, but this is not
> true in all cases. Having a struct here allows us to encapsulate the chip
> register access and to respond to changes to system hardware.
>
> We'll change the name to h_epa meaning "ehea physical address"
Hmm, I'm not convinced. Having the struct doesn't really encapsulate
much, because most of the places where you use the h_galpa struct just
pull out the fw_handle anyway. So if you change the layout of the struct
you're going to have to change most of the code anyway. And in the
meantime it makes the code a lot less readable, most people understand
what "u64 addr" is about, whereas "struct h_galpa" is much less
meaningful. </2c>
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: ehea debug output discussion
From: Michael Ellerman @ 2006-08-15 0:02 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, roland, netdev, Thomas Klein,
linux-ppc, Christoph Raisch, Anton Blanchard, Marcus Eder
In-Reply-To: <44E06EDA.6040404@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1856 bytes --]
On Mon, 2006-08-14 at 14:38 +0200, Jan-Bernd Themann wrote:
> Hi
>
> Anton Blanchard wrote:
> > What is going to be done about the debug infrastructure in the ehea
> > driver? The entry and exit traces really need to go, and any other debug
> > you think is important to users needs to go into debugfs or something
> > similar.
> >
> > I see a similar issue in the ehca driver that I am in the middle of
> > reviewing.
> >
> > Anton
>
> This is a statement for the eHEA driver:
>
> Most of the debug outputs are redundant and we'll remove them
> (EDEB_EN / EDEB_EX). We can use the standard mechanism for ethernet devices
> (netif_msg_x) in most functions of ehea_main.c as we have the device struct
> as a parameter available. However, some debug output mechanism is needed
> where the standard mechanism does not work (functions that have no relation
> to the dev struct do not have a dev parameter, for example
> ehea_hcall_9arg_9ret in ehea_phyp.h)
>
> The outcome of some internal discussions was that it is not acceptable for
> our enterprise users of this type of driver on this target system to need a
> recompile / reload of the driver for error analysis, so we need a mechanism
> that allows us to switch on / off debug output at runtime. Therefore, we'd
> introduce a stripped down version of EDEB.
Well, it might be better if the driver just worked, then your enterprise
users wouldn't need debugging output ;) ...
But if you think you need that facility then you should look at debugfs,
or relayfs, or just plain old printk, rather than implementing something
new.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-08-14 23:41 UTC (permalink / raw)
To: Geoff Levand; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <44E108B0.4070207@am.sony.com>
On Mon, Aug 14, 2006 at 04:35:12PM -0700, Geoff Levand wrote:
> Mike Kravetz wrote:
> > +config HCALL_STATS
> > + bool "Hypervisor call instrumentation"
> > + depends on PPC_PSERIES && DEBUG_FS
> > + help
> > + Adds code to keep track of the number of hypervisor calls made and
> > + the amount of time spent in hypervisor calls: both wall time (based
> > + on time base) and cpu time (based on PURR). A directory named
> > + hcall_inst is added at the root of the debugfs filesystem.
>
> Could we keep this more generic and not mention platform specific
> things like PURR?
Not sure if I follow. PURR will be used/displayed if available. Time
based statistics will always be available.
I can change the description to make this clear. Or, are you asking
that this not be mentioned at all? Based on previous discussions, I
added the ability to display both wall and cpu time if available.
Thanks,
--
Mike
^ permalink raw reply
* Re: [PATCH] powerpc: Instrument Hypervisor Calls
From: Geoff Levand @ 2006-08-14 23:35 UTC (permalink / raw)
To: Mike Kravetz; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20060814232144.GG3213@w-mikek2.ibm.com>
Mike Kravetz wrote:
> +config HCALL_STATS
> + bool "Hypervisor call instrumentation"
> + depends on PPC_PSERIES && DEBUG_FS
> + help
> + Adds code to keep track of the number of hypervisor calls made and
> + the amount of time spent in hypervisor calls: both wall time (based
> + on time base) and cpu time (based on PURR). A directory named
> + hcall_inst is added at the root of the debugfs filesystem.
Could we keep this more generic and not mention platform specific
things like PURR?
-Geoff
^ permalink raw reply
* Re: [PATCH] no-execute -- please test
From: Paul Mackerras @ 2006-08-14 23:34 UTC (permalink / raw)
To: Albert Cahalan; +Cc: linuxppc-dev, debian-powerpc
In-Reply-To: <787b0d920608132141v729665ayac50674d5ad147f4@mail.gmail.com>
Albert Cahalan writes:
> The first is to avoid taking the initial fault on the segment
> which contains the instruction pointer.
Good idea.
> The second is to avoid cache or TLB invalidates or flushes
> in certain circumstances. OpenBSD developers report that
> this type of optimization is of great benefit on sparc and ppc.
> It's an optimization than is only valid when no-execute is
> in use, so the performance effects go both ways.
We have a bit per page that says if the page is icache dirty or not.
On machines with no-execute support, we already avoid flushing the
page until some process first tries to execute from it. If we
extended that to this scheme, when we made a segment executable, we
would have to find and flush all icache-dirty pages in the segment (up
to 65536 pages). We wouldn't want to do that every time we made a
segment executable - it would need to be optimized (e.g. keep a count
per segment of icache-dirty pages in the segment).
Paul.
^ permalink raw reply
* [PATCH] powerpc: Instrument Hypervisor Calls
From: Mike Kravetz @ 2006-08-14 23:21 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Here is an updated version of the patch to instrument hypervisor
calls. In this version, all statistic updates are performed in
assembly code. Statistics are made available via debugfs.
Instrumentation is enabled via a config option and there is zero
cost if not enabled.
--
Signed-off-by: Mike Kravetz <kravetz@us.ibm.com>
diff -Naupr powerpc2/arch/powerpc/Kconfig.debug powerpc2.work/arch/powerpc/Kconfig.debug
--- powerpc2/arch/powerpc/Kconfig.debug 2006-08-14 18:00:45.000000000 +0000
+++ powerpc2.work/arch/powerpc/Kconfig.debug 2006-08-14 21:31:45.000000000 +0000
@@ -18,6 +18,20 @@ config DEBUG_STACK_USAGE
This option will slow down process creation somewhat.
+config HCALL_STATS
+ bool "Hypervisor call instrumentation"
+ depends on PPC_PSERIES && DEBUG_FS
+ help
+ Adds code to keep track of the number of hypervisor calls made and
+ the amount of time spent in hypervisor calls: both wall time (based
+ on time base) and cpu time (based on PURR). A directory named
+ hcall_inst is added at the root of the debugfs filesystem. Within
+ the hcall_inst directory are files that contain CPU specific call
+ statistics.
+
+ This option will add a small amount of overhead to all hypervisor
+ calls.
+
config DEBUGGER
bool "Enable debugger hooks"
depends on DEBUG_KERNEL
diff -Naupr powerpc2/arch/powerpc/kernel/asm-offsets.c powerpc2.work/arch/powerpc/kernel/asm-offsets.c
--- powerpc2/arch/powerpc/kernel/asm-offsets.c 2006-08-14 18:00:46.000000000 +0000
+++ powerpc2.work/arch/powerpc/kernel/asm-offsets.c 2006-08-14 22:22:49.000000000 +0000
@@ -136,6 +136,7 @@ int main(void)
DEFINE(PACA_USER_TIME, offsetof(struct paca_struct, user_time));
DEFINE(PACA_SYSTEM_TIME, offsetof(struct paca_struct, system_time));
DEFINE(PACA_SLBSHADOWPTR, offsetof(struct paca_struct, slb_shadow_ptr));
+ DEFINE(PACA_DATA_OFFSET, offsetof(struct paca_struct, data_offset));
DEFINE(LPPACASRR0, offsetof(struct lppaca, saved_srr0));
DEFINE(LPPACASRR1, offsetof(struct lppaca, saved_srr1));
@@ -160,6 +161,12 @@ int main(void)
/* Create extra stack space for SRR0 and SRR1 when calling prom/rtas. */
DEFINE(PROM_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs) + 16);
DEFINE(RTAS_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs) + 16);
+
+ /* hcall statistics */
+ DEFINE(HCALL_STAT_SIZE, sizeof(struct hcall_stats));
+ DEFINE(HCALL_STAT_CALLS, offsetof(struct hcall_stats, num_calls));
+ DEFINE(HCALL_STAT_TB, offsetof(struct hcall_stats, tb_total));
+ DEFINE(HCALL_STAT_PURR, offsetof(struct hcall_stats, purr_total));
#endif /* CONFIG_PPC64 */
DEFINE(GPR0, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[0]));
DEFINE(GPR1, STACK_FRAME_OVERHEAD+offsetof(struct pt_regs, gpr[1]));
diff -Naupr powerpc2/arch/powerpc/platforms/pseries/Makefile powerpc2.work/arch/powerpc/platforms/pseries/Makefile
--- powerpc2/arch/powerpc/platforms/pseries/Makefile 2006-08-14 18:00:55.000000000 +0000
+++ powerpc2.work/arch/powerpc/platforms/pseries/Makefile 2006-08-14 21:31:45.000000000 +0000
@@ -12,3 +12,4 @@ obj-$(CONFIG_EEH) += eeh.o eeh_cache.o e
obj-$(CONFIG_HVC_CONSOLE) += hvconsole.o
obj-$(CONFIG_HVCS) += hvcserver.o
+obj-$(CONFIG_HCALL_STATS) += hvCall_inst.o
diff -Naupr powerpc2/arch/powerpc/platforms/pseries/hvCall.S powerpc2.work/arch/powerpc/platforms/pseries/hvCall.S
--- powerpc2/arch/powerpc/platforms/pseries/hvCall.S 2006-08-14 18:00:55.000000000 +0000
+++ powerpc2.work/arch/powerpc/platforms/pseries/hvCall.S 2006-08-14 22:17:04.000000000 +0000
@@ -10,9 +10,66 @@
#include <asm/hvcall.h>
#include <asm/processor.h>
#include <asm/ppc_asm.h>
+#include <asm/asm-offsets.h>
#define STK_PARM(i) (48 + ((i)-3)*8)
+#ifdef CONFIG_HCALL_STATS
+/*
+ * precall must preserve all registers. use unused STK_PARM()
+ * areas to save snapshots and opcode.
+ */
+#define HCALL_INST_PRECALL \
+ std r3,STK_PARM(r3)(r1); /* save opcode */ \
+ mftb r3; /* get timebase and */ \
+ std r3,STK_PARM(r5)(r1); /* save for later */ \
+BEGIN_FTR_SECTION; \
+ mfspr r3,SPRN_PURR; /* get PURR and */ \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
+ std r3,STK_PARM(r6)(r1); /* save for later */ \
+ ld r3,STK_PARM(r3)(r1); /* opcode back in r3 */
+
+/*
+ * postcall is performed immediately before function return which
+ * allows liberal use of volital registers.
+ */
+#define HCALL_INST_POSTCALL \
+ /* get time and PURR snapshots after hcall */ \
+ mftb r7; /* timebase after */ \
+BEGIN_FTR_SECTION; \
+ mfspr r8,SPRN_PURR; /* PURR after */ \
+END_FTR_SECTION_IFSET(CPU_FTR_PURR); \
+ \
+ /* calculate time and PURR deltas for call */ \
+ ld r5,STK_PARM(r5)(r1); /* timebase before */ \
+ subf r5,r5,r7; \
+ ld r6,STK_PARM(r6)(r1); /* PURR before */ \
+ subf r6,r6,r8; \
+ \
+ /* calculate address of stat structure */ \
+ ld r4,STK_PARM(r3)(r1); /* use opcode as */ \
+ rldicl r4,r4,62,2; /* index into array */ \
+ mulli r4,r4,HCALL_STAT_SIZE; \
+ LOAD_REG_ADDR(r7, per_cpu__hcall_stats); \
+ add r4,r4,r7; \
+ ld r7,PACA_DATA_OFFSET(r13); /* per cpu offset */ \
+ add r4,r4,r7; \
+ \
+ /* update stats */ \
+ ld r7,HCALL_STAT_CALLS(r4); /* count */ \
+ addi r7,r7,1; \
+ std r7,HCALL_STAT_CALLS(r4); \
+ ld r7,HCALL_STAT_TB(r4); /* timebase */ \
+ add r7,r7,r5; \
+ std r7,HCALL_STAT_TB(r4); \
+ ld r7,HCALL_STAT_PURR(r4); /* PURR */ \
+ add r7,r7,r6; \
+ std r7,HCALL_STAT_PURR(r4);
+#else
+#define HCALL_INST_PRECALL
+#define HCALL_INST_POSTCALL
+#endif
+
.text
_GLOBAL(plpar_hcall_norets)
@@ -21,8 +78,12 @@ _GLOBAL(plpar_hcall_norets)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
HVSC /* invoke the hypervisor */
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
blr /* return r3 = status */
@@ -33,6 +94,8 @@ _GLOBAL(plpar_hcall)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -50,6 +113,8 @@ _GLOBAL(plpar_hcall)
std r6, 16(r12)
std r7, 24(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
@@ -61,6 +126,8 @@ _GLOBAL(plpar_hcall9)
mfcr r0
stw r0,8(r1)
+ HCALL_INST_PRECALL
+
std r4,STK_PARM(r4)(r1) /* Save ret buffer */
mr r4,r5
@@ -86,6 +153,8 @@ _GLOBAL(plpar_hcall9)
std r11,56(r12)
std r12,64(r12)
+ HCALL_INST_POSTCALL
+
lwz r0,8(r1)
mtcrf 0xff,r0
diff -Naupr powerpc2/arch/powerpc/platforms/pseries/hvCall_inst.c powerpc2.work/arch/powerpc/platforms/pseries/hvCall_inst.c
--- powerpc2/arch/powerpc/platforms/pseries/hvCall_inst.c 1970-01-01 00:00:00.000000000 +0000
+++ powerpc2.work/arch/powerpc/platforms/pseries/hvCall_inst.c 2006-08-14 22:31:31.000000000 +0000
@@ -0,0 +1,122 @@
+/*
+ * Copyright (C) 2006 Mike Kravetz IBM Corporation
+ *
+ * Hypervisor Call Instrumentation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * 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/kernel.h>
+#include <linux/percpu.h>
+#include <linux/debugfs.h>
+#include <linux/seq_file.h>
+#include <linux/cpumask.h>
+#include <asm/hvcall.h>
+#include <asm/firmware.h>
+
+DEFINE_PER_CPU(struct hcall_stats[MAX_HCALL_OPCODES+1], hcall_stats);
+
+/*
+ * Routines for displaying the statistics in debugfs
+ */
+static void *hc_start(struct seq_file *m, loff_t *pos)
+{
+ if ((int)*pos < (MAX_HCALL_OPCODES + 1))
+ return (void *)(unsigned long)(*pos + 1);
+
+ return NULL;
+}
+
+static void *hc_next(struct seq_file *m, void *p, loff_t * pos)
+{
+ ++*pos;
+
+ return hc_start(m, pos);
+}
+
+static void hc_stop(struct seq_file *m, void *p)
+{
+}
+
+static int hc_show(struct seq_file *m, void *p)
+{
+ unsigned long h_num = (unsigned long)p;
+ struct hcall_stats *hs = (struct hcall_stats *)m->private;
+
+ if (hs[h_num].num_calls)
+ seq_printf(m, "%lu %lu %lu %lu\n", h_num<<2,
+ hs[h_num].num_calls,
+ hs[h_num].tb_total,
+ hs[h_num].purr_total);
+
+ return 0;
+}
+
+static struct seq_operations hcall_inst_seq_ops = {
+ .start = hc_start,
+ .next = hc_next,
+ .stop = hc_stop,
+ .show = hc_show
+};
+
+static int hcall_inst_seq_open(struct inode *inode, struct file *file)
+{
+ int rc;
+ struct seq_file *seq;
+
+ rc = seq_open(file, &hcall_inst_seq_ops);
+ seq = file->private_data;
+ seq->private = file->f_dentry->d_inode->u.generic_ip;
+
+ return rc;
+}
+
+static struct file_operations hcall_inst_seq_fops = {
+ .open = hcall_inst_seq_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = seq_release,
+};
+
+#define HCALL_ROOT_DIR "hcall_inst"
+#define CPU_NAME_BUF_SIZE 32
+
+static int __init hcall_inst_init(void)
+{
+ struct dentry *hcall_root;
+ struct dentry *hcall_file;
+ char cpu_name_buf[CPU_NAME_BUF_SIZE];
+ int cpu;
+
+ if (!firmware_has_feature(FW_FEATURE_LPAR))
+ return 0;
+
+ hcall_root = debugfs_create_dir(HCALL_ROOT_DIR, NULL);
+ if (!hcall_root)
+ return -ENOMEM;
+
+ for_each_possible_cpu(cpu) {
+ snprintf(cpu_name_buf, CPU_NAME_BUF_SIZE, "cpu%d", cpu);
+ hcall_file = debugfs_create_file(cpu_name_buf, S_IRUGO,
+ hcall_root,
+ per_cpu(hcall_stats, cpu),
+ &hcall_inst_seq_fops);
+ if (!hcall_file)
+ return -ENOMEM;
+ }
+
+ return 0;
+}
+__initcall(hcall_inst_init);
diff -Naupr powerpc2/include/asm-powerpc/hvcall.h powerpc2.work/include/asm-powerpc/hvcall.h
--- powerpc2/include/asm-powerpc/hvcall.h 2006-08-14 18:05:16.000000000 +0000
+++ powerpc2.work/include/asm-powerpc/hvcall.h 2006-08-14 21:31:45.000000000 +0000
@@ -246,6 +246,15 @@ long plpar_hcall(unsigned long opcode, u
#define PLPAR_HCALL9_BUFSIZE 9
long plpar_hcall9(unsigned long opcode, unsigned long *retbuf, ...);
+/* For hcall instrumentation. One structure per-hcall, per-CPU */
+struct hcall_stats {
+ unsigned long num_calls; /* number of calls (on this CPU) */
+ unsigned long tb_total; /* total wall time (mftb) of calls. */
+ unsigned long purr_total; /* total cpu time (PURR) of calls. */
+};
+void update_hcall_stats(unsigned long opcode, unsigned long tb_delta,
+ unsigned long purr_delta);
+
#endif /* __ASSEMBLY__ */
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_HVCALL_H */
^ permalink raw reply
* 8260 SMC1 and SMC2 serial port problems
From: Boris Shteinbock @ 2006-08-14 22:25 UTC (permalink / raw)
To: linuxppc-embedded
Hi guys.
I am working on the Linux port on a custom 8260-based board.
During the port I've encountered a few problems with serial ports.
1. On the latest kernel 2.6.17 the cpm2 serial driver fails during the
bus scan and fails back to so called compat mode.
2. For whatever strange reason, the driver is unable to initialize
serial port, if the console on SMC is not selected.
3. I am unable to work with both SMC1 and SMC2 together. During driver
init, only one port actually gets an IRQ.
In another words, if I enable both SMC1 and SMC2 in the kernel config.
and put console on ttyCPM0, then SMC1 gets IRQ, but SMC2 doesn't. dmesg
actually prints IRQs for both ports, but looking into /proc/irq reveals,
that only one interrupt is assigned only for port that is used as a console.
2) and 3) relate for both 2.6.17 and 2.6.16 kernel trees
Could someone, please, advise me, on possible solutions for those problems ?
Thanks in advance,
Boris
^ permalink raw reply
* Re: Can red hat linux be ported to Power PC ???????????????
From: Andy Gospodarek @ 2006-08-14 17:24 UTC (permalink / raw)
To: Guy Streeter; +Cc: linuxppc-embedded
In-Reply-To: <1155575895.4044.6.camel@mentos.hsv.redhat.com>
On 8/14/06, Guy Streeter <streeter@redhat.com> wrote:
> On Mon, 2006-08-14 at 22:26 +0530, Ujwal wrote:
> > hi all,
> >
> > can red hat linux(2.4 kernel with a the .config file of ML310 board )
> > be ported to PowerPC on a development board?
>
> The ppc arch of the kernel tree was not well maintained in the Red Hat
> kernel source for the release that used the 2.4 kernel (Red Hat
> Enterprise Linux 3).
> I would be surprised if it built, and I'm fairly certain it would not
> run.
>
> That being said, Red Hat makes a business in developing its products for
> other platforms and might consider the work on a contract basis.
>
> --Guy Streeter
>
>
Is there a particular reason to use a RedHat kernel?
I would suggest using the ELDK (from denx.de) if you are looking for a
stable kernel on which to base your product/project.
-andy
^ permalink raw reply
* Re: Can red hat linux be ported to Power PC ???????????????
From: Guy Streeter @ 2006-08-14 17:18 UTC (permalink / raw)
To: Ujwal; +Cc: linuxppc-embedded
In-Reply-To: <b47d45990608140956s1a1dcdbbh8b454d0fe487a271@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 585 bytes --]
On Mon, 2006-08-14 at 22:26 +0530, Ujwal wrote:
> hi all,
>
> can red hat linux(2.4 kernel with a the .config file of ML310 board )
> be ported to PowerPC on a development board?
The ppc arch of the kernel tree was not well maintained in the Red Hat
kernel source for the release that used the 2.4 kernel (Red Hat
Enterprise Linux 3).
I would be surprised if it built, and I'm fairly certain it would not
run.
That being said, Red Hat makes a business in developing its products for
other platforms and might consider the work on a contract basis.
--Guy Streeter
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 196 bytes --]
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2151 bytes --]
^ 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