* 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: 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 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
* 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] 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
* 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: 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: 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: 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: 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
* [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: 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
* 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: 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
* 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: 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: 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
* 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: 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
* Re: [PATCH 4/6] ehea: header files
From: Jan-Bernd Themann @ 2006-08-15 9:44 UTC (permalink / raw)
To: michael
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <1155600499.9047.13.camel@localhost.localdomain>
Michael Ellerman wrote:
> 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?
>
yes, the eHEA currently supports only 4K pages for queues
>>>> +/*
>>>> + * 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
>
We already use the h_galpa struct for simulation purposes where we use
this encapsulation to add further required fields to be able to access
the registers (h_galpa has been renamed to h_epa). The name of the
fw_handle element will be changed. Instead of fw_handle, we'll call it
ebus_addr which will make it more readable.
Regards,
Jan-Bernd
^ permalink raw reply
* RE: [PATCH 4/6] ehea: header files
From: Christoph Raisch @ 2006-08-15 11:07 UTC (permalink / raw)
To: Jenkins, Clive
Cc: Thomas Q Klein, netdev, linux-kernel, linux-ppc, Marcus Eder
In-Reply-To: <35786B99AB3FDC45A821572461791973AC87D3@gbrwgceumf01.eu.xerox.net>
"Jenkins, Clive" wrote on 15.08.2006 12:53:05:
> > > You mean the eHEA has its own concept of page size? Separate from
> the
> > > page size used by the MMU?
> > >
> >
> > yes, the eHEA currently supports only 4K pages for queues
>
> In that case, I suggest use the kernel's page size, but add a
> compile-time
> check, and quit with an error message if driver does not support it.
eHEA does support other page sizes than 4k, but the HW interface expects to
see 4k pages
The adaption is done in the device driver, therefore we have a seperate 4k
define.
Regards . . . Christoph R.
^ permalink raw reply
* edlk4.0 ppc_85xx gdb problems
From: emre kara @ 2006-08-15 11:09 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <OF8C6BA147.30EE53F8-ONC12571CB.003C7748-C12571CB.003CBAA4@de.ibm.com>
Dear All;
Is there any one used 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: [PATCH 4/6] ehea: header files
From: Jenkins, Clive @ 2006-08-15 10:53 UTC (permalink / raw)
To: Jan-Bernd Themann, michael
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44E19765.7030301@de.ibm.com>
> > You mean the eHEA has its own concept of page size? Separate from
the
> > page size used by the MMU?
> >=20
>=20
> yes, the eHEA currently supports only 4K pages for queues
In that case, I suggest use the kernel's page size, but add a
compile-time
check, and quit with an error message if driver does not support it.
Regards,
Clive
^ permalink raw reply
* RE: edlk4.0 ppc_85xx gdb problems
From: Jenkins, Clive @ 2006-08-15 11:46 UTC (permalink / raw)
To: emre kara, linuxppc-dev
In-Reply-To: <20060815110933.135.qmail@web25911.mail.ukl.yahoo.com>
> ppc_85xx-gdb vmlinux
> ......
> ......
> (gdb) target remote 192.168.101.101:2001
> Remote debugging using 192.168.101.101:2001
> 0x00000000 in ?? ()
> (gdb) q
When I had this problem (actually using KGDB not BDI2000),
I found that GDB defaulted to e500 architecture (=3Dprocessor)
but it only worked with the less processor-specific
"common" architecture setting:
(gdb) show architecture
The target architecture is set automatically (currently=20
powerpc:e500)
(gdb) set architecture powerpc:common
See also:
http://www.ultsol.com/faq_p311.htm
Regards,
Clive
^ permalink raw reply
* 2.6.18-rc3->rc4 hugetlbfs regression
From: Dave Hansen @ 2006-08-15 15:22 UTC (permalink / raw)
To: Linux Kernel Mailing List, linux-mm
Cc: Suzuki Kp, PPC External List, Yao Fei Zhu, lge,
Nishanth Aravamudan
kernel BUG in cache_free_debugcheck at mm/slab.c:2748!
This is from a ppc64 machine running 2.6.18-rc4. It didn't apparently
happen with 2.6.18-rc3, but I don't see anything particularly suspect in
the changelogs, so it might be a wee bit more intermittent than it first
appeared.
You can get libhugetlbfs from here: http://libhugetlbfs.sourceforge.net/
Steps to reproduce:
1. boot kernel 2.6.18-rc4 with "hugepages=20"
2. mount none -t hugetlbfs /mnt/hugetlbfs
3. run libhugetlbfs, "make check" trigger xmon.
apple-lp1:/kernel/libhugetlbfs.git # make check
zero_filesize_segment (32): obj32/zero_filesize_segment:
obj32/zero_filesize_segment: cannot execute binary file
zero_filesize_segment (64): obj64/zero_filesize_segment:
obj64/zero_filesize_segment: cannot execute binary file
test_root (32): PASS
test_root (64): PASS
meminfo_nohuge (32): PASS
meminfo_nohuge (64): PASS
gethugepagesize (32): PASS
gethugepagesize (64): PASS
empty_mounts (32): PASS
empty_mounts (64): PASS
find_path (32): PASS
find_path (64): PASS
unlinked_fd (32): PASS
unlinked_fd (64): PASS
readback (32): PASS
Additional info:
0:mon> e
cpu 0x0: Vector: 700 (Program Check) at [c0000001cf6e3530]
pc: c0000000000c7458: .cache_free_debugcheck+0x1d0/0x2b0
lr: c0000000000c7410: .cache_free_debugcheck+0x188/0x2b0
sp: c0000001cf6e37b0
msr: 8000000000021032
current = 0xc0000001ccaf94e0
paca = 0xc000000000622300
pid = 6714, comm = readback
kernel BUG in cache_free_debugcheck at mm/slab.c:2748!
0:mon> t
[c0000001cf6e37b0] c0000000000c73cc .cache_free_debugcheck+0x144/0x2b0 (unreliable)
[c0000001cf6e3860] c0000000000c7a04 .kmem_cache_free+0xd8/0x164
[c0000001cf6e3900] c00000000002f630 .pgtable_free_tlb+0xd4/0x144
[c0000001cf6e39a0] c000000000032648 .hugetlb_free_pgd_range+0x1b8/0x26c
[c0000001cf6e3a70] c0000000000b4f68 .free_pgtables+0x90/0x134
[c0000001cf6e3b20] c0000000000b61ac .exit_mmap+0xcc/0x180
[c0000001cf6e3bd0] c00000000006209c .mmput+0x70/0x148
[c0000001cf6e3c60] c000000000067288 .exit_mm+0x118/0x138
[c0000001cf6e3cf0] c0000000000692c4 .do_exit+0x21c/0x958
[c0000001cf6e3da0] c000000000069aa8 .sys_exit_group+0x0/0x8
[c0000001cf6e3e30] c00000000000871c syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 000000000feb0b78
SP (ffcc4090) is in userspace
0:mon> r
R00 = 000000000000018f R16 = 00000000100a0000
R01 = c0000001cf6e37b0 R17 = 00000000100b2eb0
R02 = c000000000849ce0 R18 = 00000000100a0000
R03 = c0000001cfe90a08 R19 = 0000000000000000
R04 = c0000001cfe90a10 R20 = 0000000000000000
R05 = ffffffffffffffff R21 = 00000000e0ffffff
R06 = 0000000000000000 R22 = c0000001cf6e3b90
R07 = c000000000648c38 R23 = 00000000e0ffffff
R08 = 000000000001ffff R24 = 00000000e1000000
R09 = 0000000000000001 R25 = c00000000002f630
R10 = 0000000000000019 R26 = c0000001cfe90000
R11 = 0000000000000850 R27 = 0000000000000000
R12 = 0000000000000001 R28 = c0000001cfe90978
R13 = c000000000622300 R29 = 000000000000000e
R14 = 0000000010080000 R30 = c00000000065f098
R15 = 0000000000000000 R31 = c000000002b14380
pc = c0000000000c7458 .cache_free_debugcheck+0x1d0/0x2b0
lr = c0000000000c7410 .cache_free_debugcheck+0x188/0x2b0
msr = 8000000000021032 cr = 44000424
ctr = 0000000000000001 xer = 000000002000001a trap = 700
0:mon> di c0000000000c7458
c0000000000c7458 0b090000 tdnei r9,0
c0000000000c745c 801f0118 lwz r0,280(r31)
c0000000000c7460 7809bfe3 rldicl. r9,r0,55,63
c0000000000c7464 41820034 beq c0000000000c7498 #
.cache_free_debugcheck+0x210/0x2b0
c0000000000c7468 e93f0148 ld r9,328(r31)
c0000000000c746c e87f01d2 lwa r3,464(r31)
c0000000000c7470 7fe4fb78 mr r4,r31
c0000000000c7474 38a00005 li r5,5
c0000000000c7478 e9690000 ld r11,0(r9)
c0000000000c747c f8410028 std r2,40(r1)
c0000000000c7480 7c7c1a14 add r3,r28,r3
c0000000000c7484 7d6903a6 mtctr r11
c0000000000c7488 e8490008 ld r2,8(r9)
c0000000000c748c e9690010 ld r11,16(r9)
c0000000000c7490 4e800421 bctrl
c0000000000c7494 e8410028 ld r2,40(r1)
The BUG() hit here :
*dbg_redzone1(cachep, objp) = RED_INACTIVE;
*dbg_redzone2(cachep, objp) = RED_INACTIVE;
}
if (cachep->flags & SLAB_STORE_USER)
*dbg_userword(cachep, objp) = caller;
objnr = obj_to_index(cachep, slabp, objp);
BUG_ON(objnr >= cachep->num);
BUG_ON(objp != index_to_obj(cachep, slabp, objnr)); <---- Hit here.
if (cachep->flags & SLAB_DEBUG_INITIAL) {
/*
-- Dave
^ 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