* RE: How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-21 15:23 UTC (permalink / raw)
To: Morrison, Tom, Kumar Gala
Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <27AB6AE2-F8BA-4F05-9597-BCE0F98C1126@kernel.crashing.org>
Just had a little conference with several co-workers...to go over
results
We think that LT0 (the one that maps the kernel) has been corrupted:
Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
---------------------------------------------------------------
LT0 C0000000 00000000 00 0FF 04 9 0 0
PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
---------------------------------------------------------------
0 0 P P E E D E E D D V
Is absolutely wrong - this is TLB for the kernel - and as you can see=20
...it does NOT have execution privileges (and in fact the user space=20
HAS executive privileges for this area (complete opposite of what it=20
should be)...
This is why it is stuck AT that instruction (can't even single step
from that location)..
(one of) The first problem(s) is how can/when did this TLB get
corrupted!
Tom
^ permalink raw reply
* RE: How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-21 14:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <27AB6AE2-F8BA-4F05-9597-BCE0F98C1126@kernel.crashing.org>
What do you mean by 'odd' mappings (the EPN or RPNor ??)
Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
---------------------------------------------------------------
LT8 E5BF1000 995EA900 96 000 0C D 8 0
<continued>
PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
0 1 U S D E E E E D D V
We are using a 36bit address (mainly to remap our I/O and local bus
devices
to outside the 32bit addressing space)...
t
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Thursday, May 21, 2009 10:45 AM
>> To: Morrison, Tom
>> Cc: linuxppc-dev@ozlabs.org; Young, Andrew; Brown, Jeff; Geary Sean-
>> R60898
>> Subject: Re: How to debug a hung multi-core system....
>>=20
>> > [Morrison, Tom]
>> > >BKM>tat
>> >
>> > Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
>> > PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
>> >
>>=20
>> > LT0 C0000000 00000000 00 0FF 04 9 0 0
>> > 0 0 P P E E D E E D D V
>> > LT1 D0000000 01000000 00 0FF 04 9 0 0
>> > 0 0 P P E E D E E D D V
>> > LT2 E0000000 02000000 00 0FF 04 9 0 0
>> > 0 0 P P E E D E E D D V
>>=20
>> > LT4 F924E000 7C054500 BA 000 0B E 0 3
>> > 0 0 P S E E D E E D D V
>>=20
>> > LT6 80000000 1F000000 F2 0FF 1D 9 B 3
>> > 0 0 U S D E D E E E D V
>> > LT7 64000000 1F000000 B3 07F 02 8 B 0
>> > 0 1 U S D E D D E E D V
>> > LT8 E5BF1000 995EA900 96 000 0C D 8 0
>> > 0 1 U S D E E E E D D V
>>=20
>> > LT11 6B000000 F5700000 BC 03F 04 7 D 0
>> > 0 1 P S E E E E E E D V
>> > LT12 712DB000 F1B59100 2A 000 19 C F 1
>> > 0 1 P S E E E E D E D V
>> > LT13 00000000 F0000000 7F 0FF 07 B 0 0
>> > 0 1 P S D D E E E E D V
>> > LT14 A3000000 FDD00000 C5 03F 16 7 E 3
>> > 0 1 P S E E E D D E D V
>> > LT15 F7F00000 B0B80000 82 00F 1F 5 F 0
>> > 0 1 P P E E D D D D D V
>>=20
>> Do you know what the Entry field means? Are you guys putting your
own
>> mappings into the TLB? LT4..LT15 (with VAL =3D V) seem very odd to =
me.
>>=20
>> - k
^ permalink raw reply
* Re: How to debug a hung multi-core system....
From: Kumar Gala @ 2009-05-21 14:45 UTC (permalink / raw)
To: Morrison, Tom; +Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90110F53A79@EMPBEDEX.empirix.com>
> [Morrison, Tom]
> >BKM>tat
>
> Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1
> PID TS PROT SHEN UR UW UX SR SW SX TIDZ VAL
>
> LT0 C0000000 00000000 00 0FF 04 9 0 0
> 0 0 P P E E D E E D D V
> LT1 D0000000 01000000 00 0FF 04 9 0 0
> 0 0 P P E E D E E D D V
> LT2 E0000000 02000000 00 0FF 04 9 0 0
> 0 0 P P E E D E E D D V
> LT4 F924E000 7C054500 BA 000 0B E 0 3
> 0 0 P S E E D E E D D V
> LT6 80000000 1F000000 F2 0FF 1D 9 B 3
> 0 0 U S D E D E E E D V
> LT7 64000000 1F000000 B3 07F 02 8 B 0
> 0 1 U S D E D D E E D V
> LT8 E5BF1000 995EA900 96 000 0C D 8 0
> 0 1 U S D E E E E D D V
> LT11 6B000000 F5700000 BC 03F 04 7 D 0
> 0 1 P S E E E E E E D V
> LT12 712DB000 F1B59100 2A 000 19 C F 1
> 0 1 P S E E E E D E D V
> LT13 00000000 F0000000 7F 0FF 07 B 0 0
> 0 1 P S D D E E E E D V
> LT14 A3000000 FDD00000 C5 03F 16 7 E 3
> 0 1 P S E E E D D E D V
> LT15 F7F00000 B0B80000 82 00F 1F 5 F 0
> 0 1 P P E E D D D D D V
Do you know what the Entry field means? Are you guys putting your own
mappings into the TLB? LT4..LT15 (with VAL = V) seem very odd to me.
- k
^ permalink raw reply
* RE: How to debug a hung multi-core system....
From: Morrison, Tom @ 2009-05-21 13:52 UTC (permalink / raw)
To: Kumar Gala; +Cc: Geary Sean-R60898, linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <C966FFF1-23FD-4581-A001-79F6961F8E49@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 5573 bytes --]
<see middle post>
>> -----Original Message-----
>> From: Kumar Gala [mailto:galak@kernel.crashing.org]
>> Sent: Thursday, May 21, 2009 9:13 AM
>> To: Morrison, Tom
>> Cc: linuxppc-dev@ozlabs.org; Young, Andrew; Brown, Jeff
>> Subject: Re: How to debug a hung multi-core system....
>>
>>
>> On May 20, 2009, at 6:17 PM, Morrison, Tom wrote:
[Morrison, Tom]
<snip some verbose explanations>
>> >
>> > Core 1 seems to be Idle loop - happily doing nothing
>> > (and not servicing TCP and/or the console)...
>> >
>> > Core 0 seems to be 'stuck' at the "InstructionStorage"
>> > Exception. And it seems to be going 'nowhere' fast
>> >
>> > SRR0 seems to point to this same spot (0xc00006C0)
>> > SRR1 value is 0x00021200
>> >
>> > I am at a loss to see how the kernel (and/or our kernel BSP)
>> > cause this exception, and I am even more of a loss on figuring
>> > out an application could cause this exception...
>>
>> This is a bit odd as we shouldn't see an ISI from 0xc00006C0.
>>
>> Are you able to single step Core0? Can you dump the contents of the
>> TLBs on Core0
[Morrison, Tom]
[Morrison, Tom]
<snip some of verbose explanation>
Yes, very odd...
And I am able to get TLB entries from the core that is in
Instruction Storage Exception, I made
[Morrison, Tom]
>BKM>tat
Entry EPN RPN TID TMASK WIMGE TSIZ U0:3 X0:1 PID TS
PROT SHEN UR UW UX SR SW SX TIDZ VAL
IT0 0000C000 00000000 00 000 0A 0 0 0 0
0 U P D D D D D D D I
IT1 0000C000 00000000 00 000 0A 0 0 0 0
0 U P D D D D D D D I
IT2 0000C000 00000000 00 000 0A 0 0 0 0
0 U P D D D D D D D I
IT3 0000C000 00000000 00 000 0A 0 0 0 0
0 U P D D D D D D D I
DT0 0011C000 00000000 00 000 06 0 0 0 0
0 U P D D D D D D D I
DT1 D435C000 20000000 00 000 1E 0 0 0 0
0 U P D D D D D D D I
DT2 0011C000 00000000 00 000 06 0 0 0 0
0 U P D D D D D D D I
DT3 D435C000 20000000 00 000 1E 0 0 0 0
0 U P D D D D D D D I
LT0 C0000000 00000000 00 0FF 04 9 0 0 0
0 P P E E D E E D D V
LT1 D0000000 01000000 00 0FF 04 9 0 0 0
0 P P E E D E E D D V
LT2 E0000000 02000000 00 0FF 04 9 0 0 0
0 P P E E D E E D D V
LT3 39A40000 027FF700 0D 000 06 E A 3 0
1 U S D D D E E D D I
LT4 F924E000 7C054500 BA 000 0B E 0 3 0
0 P S E E D E E D D V
LT5 82A9F000 46664C00 FB 000 1A F 4 2 0
0 U S E E D D E D D I
LT6 80000000 1F000000 F2 0FF 1D 9 B 3 0
0 U S D E D E E E D V
LT7 64000000 1F000000 B3 07F 02 8 B 0 0
1 U S D E D D E E D V
LT8 E5BF1000 995EA900 96 000 0C D 8 0 0
1 U S D E E E E D D V
LT9 7F3BF000 C6DF7300 DF 000 15 1 2 3 0
1 U S E D D E E E D I
LT10 917C7000 EEA67F00 7F 000 17 C 5 3 0
1 P S E E E E E E D I
LT11 6B000000 F5700000 BC 03F 04 7 D 0 0
1 P S E E E E E E D V
LT12 712DB000 F1B59100 2A 000 19 C F 1 0
1 P S E E E E D E D V
LT13 00000000 F0000000 7F 0FF 07 B 0 0 0
1 P S D D E E E E D V
LT14 A3000000 FDD00000 C5 03F 16 7 E 3 0
1 P S E E E D D E D V
LT15 F7F00000 B0B80000 82 00F 1F 5 F 0 0
1 P P E E D D D D D V
To answer your 2nd question - we have about 10 processes, and
about 60-70 threads total (30+ for the main processing process)...
>> > Anybody have any ideas - and/or ways to re-configure our
>> > setup to obtain more data? Or does this sound familiar to
>> > a bug somebody has already found in the kernel?
>> >
>> > We are even having trouble defining a test program that can
>> > cause (on purpose) the 'InstructionStorage' Exception (does
>> > anybody have an simple 'c' (or ppc assembly) program that
>> > causes this exception (so we can run in user application land
>> > and see if the symptoms are similar))?
>> >
>> > Thank you in advance for any / all help you can provide....
>> > because I am completely stumped on even how to proceed!
>>
>>
>> Is your application generating a lot of processes or have a lot of
>> concurrent processes on the 8572?
>>
>> - k
[-- Attachment #2: Type: text/html, Size: 28598 bytes --]
^ permalink raw reply
* Re: How to debug a hung multi-core system....
From: Kumar Gala @ 2009-05-21 13:12 UTC (permalink / raw)
To: Morrison, Tom; +Cc: linuxppc-dev, Young, Andrew, Brown, Jeff
In-Reply-To: <BD261180E6D35F4D9D32F3E44FD3D90110EFACB2@EMPBEDEX.empirix.com>
On May 20, 2009, at 6:17 PM, Morrison, Tom wrote:
> All,
>
> First off, we turned SPE off completely in our build - so we
> could debug a much deeper problem that seems to be occurring
> in our application (before we try to find a potential test
> case for corruption of GPR registers).
>
> We have had this problem for 3 weeks, and just recently have
> come down to a single test case that makes it fail (although
> extremely complicated test case)...
>
> Setup:
> Master Blade (8548E) with Linux 2.6.23 (and custom BSP)
> Slave Blade (8572E) with Linux 2.6.23 (and similar custom BSP).
>
> The Master Blade works flawlessly (and also works in a slave
> capacity too flawlessly). The single 'slave' 8572E blades
> communicates with the 'master' blade over TCP/IP & PCI Express
> (and is running a similar application)...
>
> Running Single Core on slave 8572E (nosmp option on command line)
> the application works in all conditions (from modestly loaded to
> well oversubscribed/pegged CPU).
>
> In Multi-core option, the application also works flawlessly. The
> problem comes when we oversubscribe our application and push
> this 'slave' blade to the extreme edge of processing (falling
> behind in our processing...etc).
>
> Eventually, sometime between 5-15 minutes, this board becomes
> hung (where the console becomes completely unresponsive and
> you cannot 'ping' the box).
>
> I have a JTAG WindRiver ICE and connect to this blade after it
> is hung, and it appears that both cores are running to some
> extent:
>
> Core 1 seems to be Idle loop - happily doing nothing
> (and not servicing TCP and/or the console)...
>
> Core 0 seems to be 'stuck' at the "InstructionStorage"
> Exception. And it seems to be going 'nowhere' fast
>
> SRR0 seems to point to this same spot (0xc00006C0)
> SRR1 value is 0x00021200
>
> I am at a loss to see how the kernel (and/or our kernel BSP)
> cause this exception, and I am even more of a loss on figuring
> out an application could cause this exception...
This is a bit odd as we shouldn't see an ISI from 0xc00006C0.
Are you able to single step Core0? Can you dump the contents of the
TLBs on Core0
> Anybody have any ideas - and/or ways to re-configure our
> setup to obtain more data? Or does this sound familiar to
> a bug somebody has already found in the kernel?
>
> We are even having trouble defining a test program that can
> cause (on purpose) the 'InstructionStorage' Exception (does
> anybody have an simple 'c' (or ppc assembly) program that
> causes this exception (so we can run in user application land
> and see if the symptoms are similar))?
>
> Thank you in advance for any / all help you can provide....
> because I am completely stumped on even how to proceed!
Is your application generating a lot of processes or have a lot of
concurrent processes on the 8572?
- k
^ permalink raw reply
* Re: [PATCH 3/6] powerpc: add memory map support to Freescale RapidIO block
From: Li Yang @ 2009-05-21 10:43 UTC (permalink / raw)
To: Andrew Morton; +Cc: zw, netdev, linux-kernel, linuxppc-dev, davem
In-Reply-To: <20090512150552.a98dca64.akpm@linux-foundation.org>
On Wed, May 13, 2009 at 6:05 AM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Tue, 12 May 2009 16:36:00 +0800
> Li Yang <leoli@freescale.com> wrote:
>
>> + =C2=A0 =C2=A0 align =3D (size < 0x1000) ? 0x1000 : 1 << (__ilog2(size =
- 1) + 1);
>> +
>> + =C2=A0 =C2=A0 /* Align the size */
>> + =C2=A0 =C2=A0 if ((lstart + size) > (_ALIGN_DOWN(lstart, align) + alig=
n)) {
>
> __ilog2() and _ALIGN_DOWN() are powerpc-specific functions. =C2=A0It woul=
d
> be preferable to use more general helpers if possible. =C2=A0ALIGN() and =
ilog2()
> might suit here.
Will change to use ilog2().
_ALIGN_DOWN() gets a lower aligned address while ALIGN() gets a higher
address. It seems that we don't have a general helper to do the same.
- Leo
^ permalink raw reply
* Re: [PATCH 02/12] fs_enet: Add MPC5121 FEC support.
From: Piotr Zięcik @ 2009-05-21 8:34 UTC (permalink / raw)
To: Grant Likely
Cc: Becky Bruce, Wolfgang Denk, Detlev Zundel, John Rigby, netdev,
linuxppc-dev, Scott Wood
In-Reply-To: <fa686aa40905140700k3ca28ac0m74c9c161ad538abc@mail.gmail.com>
Thursday 14 May 2009 16:00:33 Grant Likely wrote:
> > MPC5121 support was added to drivers/net/fs_enet. MPC52xx uses
> > drivers/net/fec_mpc52xx.c. Do you think that creating one universal
> > driver from these two is now possible? You said that it should be easy,
> > however you also said that cache coherency issues makes this imposible.
>
> Not impossible. Hard.
I thought a bit more about merging FEC drivers and I see one problem more.
Driver fs_enet works with FEC's with own DMA engine and fec_mpc52xx.c uses
BestComm. Integration of these two drivers will need a DMA abstraction layer
to keep everything clean. Unfortuanetly BestComm driver does not provide any
abstraction - it only exports set of functions to deal with specific
hardware: FEC and PATA.
More #ifdef's will be needed to remove linking with BestComm driver if kernel
will be compiled without 52xx support and resulting code will not be much
better than existing one. Especially that new DMA abstraction layer probably
will be quite complex.
--
Best Regards.
Piotr Ziecik
^ permalink raw reply
* Re: next branch update
From: Stephen Rothwell @ 2009-05-21 8:06 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list
In-Reply-To: <1242890760.5109.1.camel@pasglop>
[-- Attachment #1: Type: text/plain, Size: 511 bytes --]
Hi Ben,
On Thu, 21 May 2009 17:26:00 +1000 Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> I updated my "next" branch with the following patches. If something
> older than a week old is missing (and not already delegated to a
> maintainer on patchwork) please let me know.
Not older than a week, but trivial and has nowhere else to go:
http://patchwork.ozlabs.org/patch/27437/
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* next branch update
From: Benjamin Herrenschmidt @ 2009-05-21 7:26 UTC (permalink / raw)
To: linuxppc-dev list
I updated my "next" branch with the following patches. If something
older than a week old is missing (and not already delegated to a
maintainer on patchwork) please let me know.
Anton Blanchard (1):
powerpc: Improve decrementer accuracy
Anton Vorontsov (6):
powerpc/85xx: Add PCI IDs for MPC8569 family processors
powerpc/85xx: Fix mpc8569emds crypto node to include SNOW unit
powerpc/85xx: Fix reg & interrupts for mpc8569emds localbus added NAND
powerpc/85xx: Add eSDHC support for MPC8569E-MDS boards
powerpc/85xx: Enable Serial RapidIO for MPC85xx MDS boards
powerpc/85xx: Add STMicro M25P40 serial flash support for MPC8569E-MDS
Becky Bruce (3):
powerpc/86xx: Add 36-bit device tree for mpc8641hpcn
powerpc: make dma_window_* in pci_controller struct avail on 32b
powerpc: Use sg->dma_length in sg_dma_len() macro on 32-bit
Geert Uytterhoeven (1):
powerpc: Keep track of emulated instructions
Geoff Levand (1):
powerpc/ps3: Use smp_request_message_ipi
Haiying Wang (7):
powerpc/85xx: clean up for mpc8568_mds name
powerpc/qe: update risc allocation for QE
net/ucc_geth: update riscTx and riscRx in ucc_geth
powerpc/qe: update QE Serial Number
net/ucc_geth: Assign six threads to Rx for UEC
powerpc/85xx: Add MPC8569MDS board support
powerpc/qe: add new qe properties for QE based chips
Jan Blunck (1):
powerpc/spufs: Remove double check for non-negative dentry
Kumar Gala (32):
powerpc/fsl: Remove cell-index from PCI nodes
powerpc: Refactor board check for PCI quirks on FSL boards with uli1575
powerpc/fsl: use of_iomap() for rstcr mapping
powerpc/85xx: Add binding for LAWs and ECM
powerpc/85xx: Add new LAW & ECM device tree nodes for all 85xx systems
powerpc/86xx: Add binding for LAWs and MCM
powerpc/86xx: Add new LAW & MCM device tree nodes for all 86xx systems
powerpc/cpm: Remove some cruft code and defines
powerpc/86xx: clean up smp init code
powerpc/fsl: Removed reg property from 85xx/86xx soc node
fsldma: Fix compile warnings
powerpc/85xx: Add MSI nodes for MPC8568/9 MDS systems
powerpc/fsl: Support unique MSI addresses per PCIe Root Complex
powerpc/8xxx: Update PCI outbound window addresses for 36-bit configs
powerpc/fsl_rio: Fix compile warnings
powerpc/fsl: Update FSL esdhc binding
powerpc/85xx: Add P2020DS board support
powerpc/fsl: Setup PCI inbound window based on actual amount of memory
powerpc: Fix up elf_read_implies_exec() usage
powerpc/pci: Clean up direct access to sysdata by indirect ops
powerpc/pci: Clean up direct access to sysdata by FSL platforms
powerpc/pci: Clean up direct access to sysdata by 52xx platforms
powerpc/pci: Clean up direct access to sysdata by 4xx platforms
powerpc/pci: Clean up direct access to sysdata by CHRP platforms
powerpc/pci: Clean up direct access to sysdata on tsi108 platforms
powerpc/pci: Clean up direct access to sysdata by powermac platforms
powerpc/pci: Clean up direct access to sysdata by RTAS
powerpc/pci: Clean up direct access to sysdata by celleb platforms
powerpc/pci: Move pseries code into pseries platform specific area
powerpc/pci: Cleanup some minor cruft
powerpc/pci: Remove redundant pcnet32 fixup
powerpc/pci: clean up direct access to sysdata by iseries platform
Li Yang (2):
powerpc/fsl_rio: use LAW address from device tree
rapidio: fix section mismatch warnings
Michael Ellerman (7):
powerpc/oprofile: Remove unused dump_pmcs() in FSL oprofile
powerpc/irq: Move #ifdef'ed body of do_IRQ() into a separate function
powerpc/irq: Move stack overflow check into a separate function
powerpc/irq: Move get_irq() comment into header
powerpc/irq: Remove fallback to __do_IRQ()
powerpc/powermac: Use generic_handle_irq() in gatwick_action()
powerpc/irq: We don't need __do_IRQ() anymore
Michael Neuling (2):
powerpc: Cleanup macros in ppc-opcode.h
powerpc: Move VSX load/stores into ppc-opcode.h
Milton Miller (2):
powerpc: Enable MMU feature sections for inline asm
powerpc: Add 2.06 tlbie mnemonics
Robert Jennings (1):
powerpc/pseries: CMO unused page hinting
Sean MacLennan (1):
powerpc: Update Warp to use leds-gpio driver
Tony Breeds (1):
powerpc/mpic: Cleanup mpic_find() implementation
Vinay Sridhar (1):
powerpc/xmon: Add dl command to dump contents of __log_buf
^ permalink raw reply
* [RFC Patch 6/6] Adapt kexec and samples code to recognise PPC64 hardware breakpoint usage
From: K.Prasad @ 2009-05-21 7:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Modify kexec code to disable DABR registers before a reboot. Adapt the samples
code to populate PPC64-arch specific fields.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/kernel/machine_kexec_64.c | 3 +++
samples/hw_breakpoint/data_breakpoint.c | 4 ++++
2 files changed, 7 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/machine_kexec_64.c
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/machine_kexec_64.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/machine_kexec_64.c
@@ -24,6 +24,7 @@
#include <asm/sections.h> /* _end */
#include <asm/prom.h>
#include <asm/smp.h>
+#include <asm/hw_breakpoint.h>
int default_machine_kexec_prepare(struct kimage *image)
{
@@ -214,6 +215,7 @@ static void kexec_prepare_cpus(void)
put_cpu();
local_irq_disable();
+ hw_breakpoint_disable();
}
#else /* ! SMP */
@@ -233,6 +235,7 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
local_irq_disable();
+ hw_breakpoint_disable();
}
#endif /* SMP */
Index: linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c
===================================================================
--- linux-2.6-tip.hbkpt.orig/samples/hw_breakpoint/data_breakpoint.c
+++ linux-2.6-tip.hbkpt/samples/hw_breakpoint/data_breakpoint.c
@@ -54,6 +54,10 @@ static int __init hw_break_module_init(v
sample_hbp.info.type = HW_BREAKPOINT_WRITE;
sample_hbp.info.len = HW_BREAKPOINT_LEN_4;
#endif /* CONFIG_X86 */
+#ifdef CONFIG_PPC64
+ sample_hbp.info.name = ksym_name;
+ sample_hbp.info.type = HW_BREAKPOINT_WRITE;
+#endif /* CONFIG_PPC64 */
sample_hbp.triggered = (void *)sample_hbp_handler;
^ permalink raw reply
* [RFC Patch 5/6] Modify Data storage exception code to recognise DABR match first
From: K.Prasad @ 2009-05-21 7:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Modify Data storage exception code to first lookout for a DABR match before
recognising a kprobe or xmon exception.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/mm/fault.c | 14 ++++++--------
1 file changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6-tip.hbkpt/arch/powerpc/mm/fault.c
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/mm/fault.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/mm/fault.c
@@ -137,6 +137,12 @@ int __kprobes do_page_fault(struct pt_re
error_code &= 0x48200000;
else
is_write = error_code & DSISR_ISSTORE;
+
+ if (error_code & DSISR_DABRMATCH) {
+ /* DABR match */
+ do_dabr(regs, address, error_code);
+ return 0;
+ }
#else
is_write = error_code & ESR_DST;
#endif /* CONFIG_4xx || CONFIG_BOOKE */
@@ -151,14 +157,6 @@ int __kprobes do_page_fault(struct pt_re
if (!user_mode(regs) && (address >= TASK_SIZE))
return SIGSEGV;
-#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
- if (error_code & DSISR_DABRMATCH) {
- /* DABR match */
- do_dabr(regs, address, error_code);
- return 0;
- }
-#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
-
if (in_atomic() || mm == NULL) {
if (!user_mode(regs))
return SIGSEGV;
^ permalink raw reply
* [RFC Patch 4/6] Modify process and processor handling code to recognise hardware debug registers
From: K.Prasad @ 2009-05-21 7:18 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Modify process handling code to recognise hardware debug registers during copy
and flush operations. Introduce a new TIF_DEBUG task flag to indicate a
process's use of debug register. Load the debug register values into a
new CPU during initialisation.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/thread_info.h | 2 ++
arch/powerpc/kernel/process.c | 18 ++++++++++++++++++
arch/powerpc/kernel/smp.c | 2 ++
3 files changed, 22 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/thread_info.h
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/thread_info.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/thread_info.h
@@ -114,6 +114,7 @@ static inline struct thread_info *curren
#define TIF_FREEZE 14 /* Freezing for suspend */
#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
#define TIF_ABI_PENDING 16 /* 32/64 bit switch needed */
+#define TIF_DEBUG 17 /* uses debug registers */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
@@ -132,6 +133,7 @@ static inline struct thread_info *curren
#define _TIF_FREEZE (1<<TIF_FREEZE)
#define _TIF_RUNLATCH (1<<TIF_RUNLATCH)
#define _TIF_ABI_PENDING (1<<TIF_ABI_PENDING)
+#define _TIF_DEBUG (1<<TIF_DEBUG)
#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP)
#define _TIF_USER_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/process.c
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/process.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/process.c
@@ -50,6 +50,7 @@
#include <asm/syscalls.h>
#ifdef CONFIG_PPC64
#include <asm/firmware.h>
+#include <asm/hw_breakpoint.h>
#endif
#include <linux/kprobes.h>
#include <linux/kdebug.h>
@@ -254,8 +255,10 @@ void do_dabr(struct pt_regs *regs, unsig
11, SIGSEGV) == NOTIFY_STOP)
return;
+#ifndef CONFIG_PPC64
if (debugger_dabr_match(regs))
return;
+#endif
/* Clear the DAC and struct entries. One shot trigger */
#if defined(CONFIG_BOOKE)
@@ -372,8 +375,13 @@ struct task_struct *__switch_to(struct t
#endif /* CONFIG_SMP */
+#ifdef CONFIG_PPC64
+ if (unlikely(test_tsk_thread_flag(new, TIF_DEBUG)))
+ arch_install_thread_hw_breakpoint(new);
+#else
if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
set_dabr(new->thread.dabr);
+#endif /* CONFIG_PPC64 */
#if defined(CONFIG_BOOKE)
/* If new thread DAC (HW breakpoint) is the same then leave it */
@@ -550,6 +558,10 @@ void show_regs(struct pt_regs * regs)
void exit_thread(void)
{
discard_lazy_cpu_state();
+#ifdef CONFIG_PPC64
+ if (unlikely(test_tsk_thread_flag(current, TIF_DEBUG)))
+ flush_thread_hw_breakpoint(current);
+#endif /* CONFIG_PPC64 */
}
void flush_thread(void)
@@ -605,6 +617,9 @@ int copy_thread(unsigned long clone_flag
struct pt_regs *childregs, *kregs;
extern void ret_from_fork(void);
unsigned long sp = (unsigned long)task_stack_page(p) + THREAD_SIZE;
+#ifdef CONFIG_PPC64
+ struct task_struct *tsk = current;
+#endif
CHECK_FULL_REGS(regs);
/* Copy registers */
@@ -672,6 +687,9 @@ int copy_thread(unsigned long clone_flag
* function.
*/
kregs->nip = *((unsigned long *)ret_from_fork);
+
+ if (unlikely(test_tsk_thread_flag(tsk, TIF_DEBUG)))
+ copy_thread_hw_breakpoint(tsk, p, clone_flags);
#else
kregs->nip = (unsigned long)ret_from_fork;
#endif
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/smp.c
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/smp.c
@@ -48,6 +48,7 @@
#include <asm/vdso_datapage.h>
#ifdef CONFIG_PPC64
#include <asm/paca.h>
+#include <asm/hw_breakpoint.h>
#endif
#ifdef DEBUG
@@ -536,6 +537,7 @@ int __devinit start_secondary(void *unus
local_irq_enable();
+ load_debug_registers();
cpu_idle();
return 0;
}
^ permalink raw reply
* [RFC Patch 3/6] Modify ptrace code to use Hardware Breakpoint interfaces
From: K.Prasad @ 2009-05-21 7:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Modify the ptrace code to use the hardware breakpoint interfaces for user-space.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/kernel/ptrace.c | 45 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 45 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
@@ -37,6 +37,7 @@
#include <asm/page.h>
#include <asm/pgtable.h>
#include <asm/system.h>
+#include <asm/hw_breakpoint.h>
/*
* does not yet catch signals sent when the child dies.
@@ -735,9 +736,22 @@ void user_disable_single_step(struct tas
clear_tsk_thread_flag(task, TIF_SINGLESTEP);
}
+static void ptrace_triggered(struct hw_breakpoint *bp, struct pt_regs *regs)
+{
+ /*
+ * The SIGTRAP signal is generated automatically for us in do_dabr().
+ * We don't have to do anything here
+ */
+}
+
int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
unsigned long data)
{
+#ifdef CONFIG_PPC64
+ struct thread_struct *thread = &(task->thread);
+ struct hw_breakpoint *bp;
+ int ret;
+#endif
/* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
* For embedded processors we support one DAC and no IAC's at the
* moment.
@@ -767,6 +781,37 @@ int ptrace_set_debugreg(struct task_stru
if (data && !(data & DABR_TRANSLATION))
return -EIO;
+#ifdef CONFIG_PPC64
+ bp = thread->hbp[0];
+ if ((data & ~HW_BREAKPOINT_ALIGN) == 0) {
+ if (bp) {
+ unregister_user_hw_breakpoint(task, bp);
+ kfree(bp);
+ thread->hbp[0] = NULL;
+ }
+ return 0;
+ }
+
+ if (bp) {
+ bp->info.type = data & HW_BREAKPOINT_RW;
+ task->thread.dabr = bp->info.address =
+ (data & ~HW_BREAKPOINT_ALIGN);
+ return modify_user_hw_breakpoint(task, bp);
+ }
+ bp = kzalloc(sizeof(struct hw_breakpoint), GFP_KERNEL);
+ if (!bp)
+ return -ENOMEM;
+
+ /* Store the type of breakpoint */
+ bp->info.type = data & HW_BREAKPOINT_RW;
+ bp->triggered = ptrace_triggered;
+ task->thread.dabr = bp->info.address = (data & ~HW_BREAKPOINT_ALIGN);
+
+ ret = register_user_hw_breakpoint(task, bp);
+ if (ret)
+ return ret;
+#endif /* CONFIG_PPC64 */
+
/* Move contents to the DABR register */
task->thread.dabr = data;
^ permalink raw reply
* [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpoint interfaces
From: K.Prasad @ 2009-05-21 7:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Introduce PPC64 implementation for the generic hardware breakpoint interfaces
defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and the
Makefile.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/Kconfig | 1
arch/powerpc/kernel/Makefile | 2
arch/powerpc/kernel/hw_breakpoint.c | 281 ++++++++++++++++++++++++++++++++++++
3 files changed, 283 insertions(+), 1 deletion(-)
Index: linux-2.6-tip.hbkpt/arch/powerpc/Kconfig
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/Kconfig 2009-05-21 11:05:07.000000000 +0530
+++ linux-2.6-tip.hbkpt/arch/powerpc/Kconfig 2009-05-21 11:38:30.000000000 +0530
@@ -125,6 +125,7 @@
select USE_GENERIC_SMP_HELPERS if SMP
select HAVE_OPROFILE
select HAVE_SYSCALL_WRAPPERS if PPC64
+ select HAVE_HW_BREAKPOINT if PPC64
config EARLY_PRINTK
bool
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/Makefile 2009-05-21 11:05:07.000000000 +0530
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/Makefile 2009-05-21 11:38:30.000000000 +0530
@@ -33,7 +33,7 @@
signal_64.o ptrace32.o \
paca.o cpu_setup_ppc970.o \
cpu_setup_pa6t.o \
- firmware.o nvram_64.o
+ firmware.o nvram_64.o hw_breakpoint.o
obj64-$(CONFIG_RELOCATABLE) += reloc_64.o
obj-$(CONFIG_PPC64) += vdso64/
obj-$(CONFIG_ALTIVEC) += vecemu.o vector.o
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c
===================================================================
--- /dev/null 1970-01-01 00:00:00.000000000 +0000
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/hw_breakpoint.c 2009-05-21 11:38:58.000000000 +0530
@@ -0,0 +1,281 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers.
+ */
+
+/*
+ * 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.
+ *
+ * Copyright © 2009 IBM Corporation
+ */
+
+#include <linux/notifier.h>
+#include <linux/kallsyms.h>
+#include <linux/kprobes.h>
+#include <linux/percpu.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/sched.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+
+#include <asm/hw_breakpoint.h>
+#include <asm/processor.h>
+#include <asm/sstep.h>
+
+/* Store the kernel-space breakpoint address value */
+static unsigned long kdabr;
+
+/*
+ * Temporarily stores address for DABR before it is written by the
+ * single-step handler routine
+ */
+static DEFINE_PER_CPU(unsigned long, dabr_data);
+
+void arch_update_kernel_hw_breakpoint(void *unused)
+{
+ struct hw_breakpoint *bp;
+
+ /* Check if there is nothing to update */
+ if (hbp_kernel_pos == HBP_NUM)
+ return;
+
+ per_cpu(this_hbp_kernel[hbp_kernel_pos], get_cpu()) = bp =
+ hbp_kernel[hbp_kernel_pos];
+ if (bp == NULL)
+ kdabr = 0;
+ else
+ kdabr = bp->info.address | bp->info.type | DABR_TRANSLATION;
+ set_dabr(kdabr);
+ put_cpu_no_resched();
+}
+
+/*
+ * Install the thread breakpoints in their debug registers.
+ */
+void arch_install_thread_hw_breakpoint(struct task_struct *tsk)
+{
+ set_dabr(tsk->thread.dabr);
+}
+
+/*
+ * Install the debug register values for just the kernel, no thread.
+ */
+void arch_uninstall_thread_hw_breakpoint()
+{
+ set_dabr(0);
+}
+
+/*
+ * Store a breakpoint's encoded address, length, and type.
+ */
+int arch_store_info(struct hw_breakpoint *bp, struct task_struct *tsk)
+{
+ /*
+ * User-space requests will always have the address field populated
+ * Symbol names from user-space are rejected
+ */
+ if (tsk && bp->info.name)
+ return -EINVAL;
+ /*
+ * User-space requests will always have the address field populated
+ * For kernel-addresses, either the address or symbol name can be
+ * specified.
+ */
+ if (bp->info.name)
+ bp->info.address = (unsigned long)
+ kallsyms_lookup_name(bp->info.name);
+ if (bp->info.address)
+ return 0;
+ return -EINVAL;
+}
+
+/*
+ * Validate the arch-specific HW Breakpoint register settings
+ */
+int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+ struct task_struct *tsk)
+{
+ int is_kernel, ret = -EINVAL;
+
+ if (!bp)
+ return ret;
+
+ switch (bp->info.type) {
+ case HW_BREAKPOINT_READ:
+ case HW_BREAKPOINT_WRITE:
+ case HW_BREAKPOINT_RW:
+ break;
+ default:
+ return ret;
+ }
+
+ if (bp->triggered)
+ ret = arch_store_info(bp, tsk);
+
+ /* Check for double word alignment - 8 bytes */
+ if (bp->info.address & HW_BREAKPOINT_ALIGN)
+ return -EINVAL;
+
+ is_kernel = is_kernel_addr(bp->info.address);
+ if ((tsk && is_kernel) || (!tsk && !is_kernel))
+ return -EINVAL;
+
+ return ret;
+}
+
+void arch_update_user_hw_breakpoint(int pos, struct task_struct *tsk)
+{
+ struct thread_struct *thread = &(tsk->thread);
+ struct hw_breakpoint *bp = thread->hbp[0];
+
+ if (bp)
+ thread->dabr = bp->info.address | bp->info.type |
+ DABR_TRANSLATION;
+ else
+ thread->dabr = 0;
+}
+
+void arch_flush_thread_hw_breakpoint(struct task_struct *tsk)
+{
+ struct thread_struct *thread = &(tsk->thread);
+
+ thread->dabr = 0;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_handler(struct die_args *args)
+{
+ int rc = NOTIFY_STOP;
+ struct hw_breakpoint *bp;
+ struct pt_regs *regs = args->regs;
+ unsigned long dar;
+ int cpu, stepped = 1;
+
+ /* Disable breakpoints during exception handling */
+ set_dabr(0);
+ dar = regs->dar & (~HW_BREAKPOINT_ALIGN);
+
+ cpu = get_cpu();
+ /* Determine whether kernel- or user-space address is the trigger */
+ bp = (hbp_kernel_pos == HBP_NUM) ? current->thread.hbp[0] :
+ per_cpu(this_hbp_kernel[0], cpu);
+ /*
+ * bp can be NULL due to lazy debug register switching
+ * or due to the delay between updates of hbp_kernel_pos
+ * and this_hbp_kernel.
+ */
+ if (!bp)
+ goto out;
+
+ if (dar == bp->info.address)
+ per_cpu(dabr_data, cpu) = (hbp_kernel_pos == HBP_NUM) ?
+ current->thread.dabr : kdabr;
+ else {
+ /*
+ * This exception is triggered because of other sources such as
+ * Xmon or kprobe and does not belong to us. Return NOTIFY_DONE.
+ */
+ rc = NOTIFY_DONE;
+ goto out;
+ }
+ (bp->triggered)(bp, regs);
+
+ stepped = emulate_step(regs, regs->nip);
+ /*
+ * Single-step the causative instruction manually if
+ * emulate_step() could not execute it
+ */
+ if (stepped == 0) {
+ regs->msr |= MSR_SE;
+ goto out;
+ }
+ set_dabr(per_cpu(dabr_data, cpu));
+ per_cpu(dabr_data, cpu) = 0;
+
+out:
+ /* Enable pre-emption only if single-stepping is finished */
+ if (stepped)
+ put_cpu_no_resched();
+ return rc;
+}
+
+/*
+ * Handle single-step exceptions following a DABR hit.
+ */
+int __kprobes single_step_dabr_instruction(struct die_args *args)
+{
+ struct pt_regs *regs = args->regs;
+ int cpu = get_cpu();
+ int ret = NOTIFY_DONE;
+ siginfo_t info;
+ unsigned long this_dabr_data = per_cpu(dabr_data, cpu);
+
+ /*
+ * Check if we are single-stepping as a result of a
+ * previous HW Breakpoint exception
+ */
+ if (this_dabr_data == 0)
+ goto out;
+
+ regs->msr &= ~MSR_SE;
+ /* Deliver signal to user-space */
+ if (this_dabr_data < TASK_SIZE) {
+ info.si_signo = SIGTRAP;
+ info.si_errno = 0;
+ info.si_code = TRAP_HWBKPT;
+ info.si_addr = (void __user *)(per_cpu(dabr_data, cpu));
+ force_sig_info(SIGTRAP, &info, current);
+ }
+
+ set_dabr(this_dabr_data);
+ per_cpu(dabr_data, cpu) = 0;
+ ret = NOTIFY_STOP;
+ /*
+ * If single-stepped after hw_breakpoint_handler(), pre-emption is
+ * already disabled.
+ */
+ put_cpu_no_resched();
+
+out:
+ /*
+ * A put_cpu_no_resched() call is required to complement the get_cpu()
+ * call used initially
+ */
+ put_cpu_no_resched();
+ return ret;
+}
+
+/*
+ * Handle debug exception notifications.
+ */
+int __kprobes hw_breakpoint_exceptions_notify(
+ struct notifier_block *unused, unsigned long val, void *data)
+{
+ int ret = NOTIFY_DONE;
+
+ switch (val) {
+ case DIE_DABR_MATCH:
+ ret = hw_breakpoint_handler(data);
+ break;
+ case DIE_SSTEP:
+ ret = single_step_dabr_instruction(data);
+ break;
+ }
+
+ return ret;
+}
^ permalink raw reply
* [RFC Patch 1/6] Prepare the PowerPC platform for HW Breakpoint infrastructure
From: K.Prasad @ 2009-05-21 7:17 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
K.Prasad, Roland McGrath
In-Reply-To: <20090521070751.156865078@prasadkr_t60p.in.ibm.com>
Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
relevant constant definitions and function declarations.
Signed-off-by: K.Prasad <prasad@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/hw_breakpoint.h | 57 +++++++++++++++++++++++++++++++
arch/powerpc/include/asm/processor.h | 1
arch/powerpc/include/asm/reg.h | 3 +
3 files changed, 61 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/hw_breakpoint.h
===================================================================
--- /dev/null
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,57 @@
+#ifndef _PPC64_HW_BREAKPOINT_H
+#define _PPC64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define __ARCH_HW_BREAKPOINT_H
+#ifdef CONFIG_PPC64
+
+struct arch_hw_breakpoint {
+ char *name; /* Contains name of the symbol to set bkpt */
+ unsigned long address;
+ u8 type;
+};
+
+#include <linux/kdebug.h>
+#include <asm/reg.h>
+#include <asm-generic/hw_breakpoint.h>
+
+#define HW_BREAKPOINT_READ DABR_DATA_READ
+#define HW_BREAKPOINT_WRITE DABR_DATA_WRITE
+#define HW_BREAKPOINT_RW (DABR_DATA_READ | DABR_DATA_WRITE)
+
+#define HW_BREAKPOINT_ALIGN 0x7
+#define HW_BREAKPOINT_LEN INSTRUCTION_LEN
+
+extern struct hw_breakpoint *hbp_kernel[HBP_NUM];
+DECLARE_PER_CPU(struct hw_breakpoint*, this_hbp_kernel[HBP_NUM]);
+extern unsigned int hbp_user_refcount[HBP_NUM];
+
+extern void arch_install_thread_hw_breakpoint(struct task_struct *tsk);
+extern void arch_uninstall_thread_hw_breakpoint(void);
+extern int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+ struct task_struct *tsk);
+extern void arch_update_user_hw_breakpoint(int pos, struct task_struct *tsk);
+extern void arch_flush_thread_hw_breakpoint(struct task_struct *tsk);
+extern void arch_update_kernel_hw_breakpoint(void *);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+
+extern void flush_thread_hw_breakpoint(struct task_struct *tsk);
+extern int copy_thread_hw_breakpoint(struct task_struct *tsk,
+ struct task_struct *child, unsigned long clone_flags);
+extern void load_debug_registers(void );
+
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#else
+static inline void hw_breakpoint_disable(void)
+{
+ /* Function is defined only on PPC64 for now */
+}
+#endif /* CONFIG_PPC64 */
+#endif /* __KERNEL__ */
+#endif /* _PPC64_HW_BREAKPOINT_H */
+
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/processor.h
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/processor.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/processor.h
@@ -177,6 +177,7 @@ struct thread_struct {
#ifdef CONFIG_PPC64
unsigned long start_tb; /* Start purr when proc switched in */
unsigned long accum_tb; /* Total accumilated purr for process */
+ struct hw_breakpoint *hbp[HBP_NUM];
#endif
unsigned long dabr; /* Data address breakpoint register */
#ifdef CONFIG_ALTIVEC
Index: linux-2.6-tip.hbkpt/arch/powerpc/include/asm/reg.h
===================================================================
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/include/asm/reg.h
+++ linux-2.6-tip.hbkpt/arch/powerpc/include/asm/reg.h
@@ -26,6 +26,8 @@
#include <asm/reg_8xx.h>
#endif /* CONFIG_8xx */
+#define INSTRUCTION_LEN 4 /* Length of any instruction */
+
#define MSR_SF_LG 63 /* Enable 64 bit mode */
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
#define MSR_HV_LG 60 /* Hypervisor state */
@@ -184,6 +186,7 @@
#define CTRL_TE 0x00c00000 /* thread enable */
#define CTRL_RUNLATCH 0x1
#define SPRN_DABR 0x3F5 /* Data Address Breakpoint Register */
+#define HBP_NUM 1 /* Number of physical HW breakpoint registers */
#define DABR_TRANSLATION (1UL << 2)
#define DABR_DATA_WRITE (1UL << 1)
#define DABR_DATA_READ (1UL << 0)
^ permalink raw reply
* [RFC Patch 0/6] PPC64: Hardware Breakpoint interfaces - ver III
From: K.Prasad @ 2009-05-21 7:16 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Neuling, Benjamin Herrenschmidt, Alan Stern, paulus,
Roland McGrath
Hi All,
Please find a new patchset that includes suggestions from the community
and a few issues discovered during code inspection and testing. The changes are
as documented below.
Kindly let me know your comments on the same, in the absence of which I intend
to submit the patchset for upstream inclusion in the subsequent iteration.
Changelog - ver III
------------------
(Ver I: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/071942.html)
(Ver II: http://ozlabs.org/pipermail/linuxppc-dev/2009-May/072106.html)
19th May 2009
--------------
- Patches are based on commit 08f16e060bf54bdc34f800ed8b5362cdeda75d8b of -tip
tree.
- The declarations in arch/powerpc/include/asm/hw_breakpoint.h are done only if
CONFIG_PPC64 is defined. This eliminates the need to conditionally include this
header file.
- load_debug_registers() is done in start_secondary() i.e. during CPU
initialisation.
- arch_check_va_<> routines in hw_breakpoint.c are now replaced with a much
simpler is_kernel_addr() check in arch_validate_hwbkpt_settings()
- Return code of hw_breakpoint_handler() when triggered due to Lazy debug
register switching is now changed to NOTIFY_STOP.
- The ptrace code no longer sets the TIF_DEBUG task flag as it is proposed to
be done in register_user_hw_breakpoint() routine.
- hw_breakpoint_handler() is now modified to use hbp_kernel_pos value to
determine if the trigger was a user/kernel space address. The DAR register
value is checked with the address stored in 'struct hw_breakpoint' to avoid
handling of exceptions that belong to kprobe/Xmon.
Thanks,
K.Prasad
^ permalink raw reply
* Re: [RFC Patch 2/6] Introduce PPC64 specific Hardware Breakpointinterfaces
From: K.Prasad @ 2009-05-21 7:15 UTC (permalink / raw)
To: Alan Stern
Cc: Michael Neuling, Benjamin Herrenschmidt, linuxppc-dev, paulus,
Roland McGrath
In-Reply-To: <Pine.LNX.4.44L0.0905181227180.3136-100000@iolanthe.rowland.org>
On Mon, May 18, 2009 at 12:30:41PM -0400, Alan Stern wrote:
> On Mon, 18 May 2009, K.Prasad wrote:
>
> > > > > > +int __kprobes hw_breakpoint_handler(struct die_args *args)
> > > > > > +{
> > > > > > + int rc = NOTIFY_STOP;
> > > > > > + struct hw_breakpoint *bp;
> > > > > > + struct pt_regs *regs = args->regs;
> > > > > > + unsigned long dar;
> > > > > > + int cpu, stepped, is_kernel;
> > > > > > +
> > > > > > + /* Disable breakpoints during exception handling */
> > > > > > + set_dabr(0);
> > > > > > +
> > > > > > + dar = regs->dar & (~HW_BREAKPOINT_ALIGN);
> > > > > > + is_kernel = (dar >= TASK_SIZE) ? 1 : 0;
> > > > >
> > > > > is_kernel_addr() ?
> > > > >
> > > >
> > > > Ok.
> > >
> > > Shouldn't this test hbp_kernel_pos instead?
> > >
> >
> > Testing hbp_kernel_pos should be sufficient for PPC64 with just one
> > breakpoint register. However the above code is more extensible to other
> > PowerPC implementations which have more than one breakpoint register.
>
> Then maybe you don't want to test this at all. Just compare the dar
> value with each of the breakpoint addresses. That's more like what the
> x86 code does.
>
> Alan Stern
>
Comparing the DAR register value with each breakpoint address is
required to determine if the exception is the cause of a breakpoint hit
and I've added the code to hw_breakpoint_handler(). With this check in
place, I find that using hbp_kernel_pos to determine kernel/user space
origin is much easier (as you suggested) and the code is modified
accordingly.
Please find the changes in the new patchset being sent.
Thanks,
K.Prasad
^ permalink raw reply
* problem in registering the device while inserting the kernel module
From: patel rajendra @ 2009-05-21 6:20 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 9116 bytes --]
Hi Members of linuxppc,
I'm working on XUPV2P board with Virtex II Pro FPGA device.
I written a kernel module for LED device. I got that module run
successfuly on ML403 board having Virtex 4 FPGA.I have not make any
change in my source code for XUP board, because I don't feel any change is required.
On XUP board when I run "insmod xilinx_led.ko" command on my target board, I got following message.
# insmod xilinx_led.ko
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: d1006190 LR: d1006188 CTR: 00000000
REGS: c0705db0 TRAP: 0300 Not tainted (2.6.23xlnx)
MSR: 00029030 <EE,ME,IR,DR> CR: 24000024 XER: 00000000
DEAR: 0000004c, ESR: 00000000
TASK = c04c63d0[186] 'insmod' THREAD: c0704000
GPR00: d1006188 c0705e60 c04c63d0 00000000 000000d0 00000001 00000000 c0220ae0
GPR08: c006c60c 00000000 00000001 c04553f0 026f4bac 100b4260 d1003288 d1007668
GPR16: d1003288 d1003238 0000fff1 0000fff2 0000004c 00000000 d100762c c003e94c
GPR24: d1002e02 00000018 d1002000 00000019 d1000000 d1007598 d10077c8 00000000
NIP [d1006190] xilinx_ml403_led_setup+0x174/0x1dc [xilinx_led]
LR [d1006188] xilinx_ml403_led_setup+0x16c/0x1dc [xilinx_led]
Call Trace:
[c0705e60] [d1006188] xilinx_ml403_led_setup+0x16c/0x1dc [xilinx_led] (unreliable)
[c0705e90] [c0040be0] sys_init_module+0x120c/0x12f8
[c0705f40] [c0002c10] ret_from_syscall+0x0/0x3c
Instruction dump:
48000819 3d20d100 39297620 913f003c 93bf0040 3c800fc0 60840001 7fe3fb78
38a00001 48000805 813e0014 7c7f1b78 <80e9004c> 3c60d100 3c80d100 80bc77c8
Note: After above output when I execute "lsmod" command. I observed that led device is tainted.
~ # lsmod
Module Size Used by Tainted: G
xilinx_led 6172 1
~ #
What I understood from above message is that there is a problem in registering the device in function xilinx_ml403_led_setup( ).
Anyone can help me out to solve this problem?
The source code is given below.
Rajendra
---------------------------------------Xilinx_led.c---------------------------------------------------------------
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/fs.h>
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/mm.h>
#include <linux/cdev.h>
#include <linux/proc_fs.h>
#include <linux/fcntl.h>
#include <linux/ioport.h>
#include <linux/interrupt.h>
#include <linux/xilinx_devices.h>
#include <asm/system.h>
#include <asm/io.h>
#include <asm/uaccess.h>
#include "xparameters.h"
#include "xio.h"
#include "xgpio.h"
#include "xgpio_l.h"
#include "xstatus.h"
#include "xbasic_types.h"
/* LED constant */
#define DRIVER_NAME "led"
#define DRIVER_DESCRIPTION "GPIO based 4 bit led peripheral driver"
#define LED_PHY_BASEADDR XPAR_LEDS_4BIT_BASEADDR
#define LED_PHY_HIGHADDR XPAR_LEDS_4BIT_HIGHADDR
#define LED_DEVICE_ID XPAR_LEDS_4BIT_DEVICE_ID
#define LED_MAJOR 252
#define LED_MINOR 1
#define LEDChan 1
XGpio gp_out;
/* Device Structure */
struct led_instance
{
Xuint32 phy_baseaddr;
Xuint32 phy_highaddr;
Xuint32 remap_size;
Xuint32 virtual_baseaddr;
u32 device_id;
struct cdev *cdev;
XGpio gpio;
};
struct led_instance xilinx_ml403_led;
/*Open and Release method */
int led_open(struct inode *inode, struct file *filp)
{
struct led_instance *dev;
dev = container_of(inode -> i_cdev, struct led_instance, cdev);
filp -> private_data = dev;
return 0;
}
int led_release(struct inode *inode, struct file *filp)
{
return 0;
}
/* Read Method */
ssize_t led_read(struct file *flip, char __user *buf, size_t count, loff_t *f_pos)
{
size_t retval = 0;
u32 data;
printk(KERN_INFO "%s: Entering\n\r", __FUNCTION__);
if(*f_pos >= sizeof(data))
{
goto out01;
}
if(*f_pos + count >= sizeof(data))
{
count = sizeof(data) - *f_pos;
}
data = XGpio_DiscreteRead(&gp_out, LEDChan);
printk(KERN_INFO "data = 0x%08X!\n\r", data);
if(copy_to_user(buf, &data, count))
{
retval = -EFAULT;
goto out01;
}
*f_pos += count;
retval = count;
out01: return retval;
}
/* Write Method */
ssize_t led_write(struct file *flip, const char __user *buf, size_t count, loff_t *f_pos)
{
size_t retval = 0;
Xuint32 data;
printk(KERN_INFO "%s: Entering\n\r", __FUNCTION__);
if(count < sizeof(data))
{
printk("argument to small!\n\r");
retval = -EINVAL;
goto out01;
}
if(*f_pos + count >= sizeof(data))
{
count = sizeof(data) - *f_pos;
}
if(copy_from_user(&data,buf, count))
{
retval = -EFAULT;
goto out01;
}
XGpio_DiscreteWrite(&gp_out,LEDChan,data);
*f_pos += count;
retval = count;
out01: return retval;
}
/* File Operations Structure */
struct file_operations led_fops = {
owner: THIS_MODULE,
open: led_open,
read: led_read,
write: led_write,
release:led_release
};
/* Device Registration */
int xilinx_ml403_led_setup(void)
{
XGpio_Config xgpio_config;
struct cdev *cdev=0;
int retval = 0;
dev_t devno;
memset(&xilinx_ml403_led, 0, sizeof(struct led_instance));
/* Map the control registers in */
/* get baseaddress and highaddress */
xilinx_ml403_led.phy_baseaddr = LED_PHY_BASEADDR;
xilinx_ml403_led.remap_size = LED_PHY_HIGHADDR - LED_PHY_BASEADDR + 1;
xilinx_ml403_led.device_id = LED_DEVICE_ID;
if(!xilinx_ml403_led.phy_baseaddr ||
(xilinx_ml403_led.remap_size - xilinx_ml403_led.phy_baseaddr + 1 <
8))
{
printk(KERN_ERR "%s: Couldn't get registers resource\n\r","led");
retval = -EFAULT;
goto failed1;
}
if(!request_mem_region(xilinx_ml403_led.phy_baseaddr, xilinx_ml403_led.remap_size, DRIVER_NAME))
{
printk(KERN_ERR "Couldn't lock
memory region at 0x%08lX\n\r",(unsigned long)
xilinx_ml403_led.phy_baseaddr);
retval = -EBUSY;
goto failed2;
}
xilinx_ml403_led.virtual_baseaddr = ioremap(xilinx_ml403_led.phy_baseaddr, xilinx_ml403_led.remap_size);
if(!xilinx_ml403_led.virtual_baseaddr)
{
printk(KERN_ERR "Couldn't ioremap
memory at 0x%08lX\n\r", (unsigned long) xilinx_ml403_led.phy_baseaddr);
retval = -EFAULT;
goto failed3;
}
if(XGpio_CfgInitialize(&gp_out, &xgpio_config,xilinx_ml403_led.virtual_baseaddr) != XST_SUCCESS)
{
printk(KERN_ERR "%s: Couldn't initialize instance.\n\r","xilinx_led");
retval = -ENODEV;
goto failed3;
}
XGpio_SetDataDirection(&gp_out, LEDChan , 0x00000000);
cdev= kmalloc(sizeof(struct cdev), GFP_KERNEL);
if(!cdev)
{
printk(KERN_ERR "%s: Couldn't allocate device private record\n\r","led");
return -ENOMEM;
}
memset(cdev,0,sizeof(struct cdev));
cdev_init(cdev,&led_fops);
cdev->owner = THIS_MODULE;
cdev->ops = &led_fops;
devno = MKDEV(LED_MAJOR,LED_MINOR);
retval = cdev_add(cdev,devno,1);
xilinx_ml403_led.cdev;
printk(KERN_ERR "%s at 0x%081X mapped to 0x%08X
device:%u,%u\n\r","xilinx_led",xilinx_ml403_led.phy_baseaddr,(unsigned
int) xilinx_ml403_led.virtual_baseaddr,(unsigned
int)MAJOR(xilinx_ml403_led.cdev->dev),(unsigned
int)MINOR(xilinx_ml403_led.cdev->dev));
failed3:
iounmap((void *) (xilinx_ml403_led.phy_baseaddr));
failed2:
release_mem_region(xilinx_ml403_led.phy_baseaddr,xilinx_ml403_led.remap_size);
failed1:
return retval;
}
int __init led_init(void)
{
int retval;
retval=xilinx_ml403_led_setup();
if(retval)
return retval;
return 0;
}
void __exit led_exit(void)
{
cdev_del(xilinx_ml403_led.cdev);
iounmap((void *)(xilinx_ml403_led.virtual_baseaddr));
release_mem_region(xilinx_ml403_led.phy_baseaddr,xilinx_ml403_led..remap_size);
}
module_init(led_init);
module_exit(led_exit);
MODULE_AUTHOR("SANDEEPANI - SCHOOL OF EMBEDDDED DESIGN");
MODULE_DESCRIPTION(DRIVER_DESCRIPTION);
MODULE_LICENSE("Dual BSD/GPL");
Explore your hobbies and interests. Go to http://in.promos.yahoo.com/groups/
[-- Attachment #2: Type: text/html, Size: 17275 bytes --]
^ permalink raw reply
* Re: problem in registering the device while inserting the kernel module
From: Grant Likely @ 2009-05-21 4:36 UTC (permalink / raw)
To: patel rajendra; +Cc: linuxppc-dev
In-Reply-To: <246420.44978.qm@web94801.mail.in2.yahoo.com>
On Wed, May 20, 2009 at 7:48 PM, patel rajendra <rdpatel55@yahoo.co.in> wrote:
> Hi Members of linuxppc,
[...]
> What I understood from above message is that there is a problem in
> registering the device in function xilinx_ml403_led_setup( ).
>
> Anyone can help me out to solve this problem?
You really need to post your code before anyone will be able to help
you. We're not mind readers.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Grant Likely @ 2009-05-21 4:21 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <20090521004626.GA1635@pengutronix.de>
On Wed, May 20, 2009 at 6:46 PM, Wolfram Sang <w.sang@pengutronix.de> wrote=
:
>> > + =A0 =A0 =A0 name =3D of_get_property(op->node, "name", NULL);
>> > + =A0 =A0 =A0 if (!name) {
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 ret =3D -ENOENT;
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 dev_dbg(&op->dev, "could not get node na=
me\n");
>> > + =A0 =A0 =A0 =A0 =A0 =A0 =A0 goto bad1;
>> > + =A0 =A0 =A0 }
>
> Can I just use
>
> =A0 =A0 =A0 =A0name =3D op->node->name
>
> here? I wonder because of_device in asm/of_device.h states 'node' as "to =
be
> obsoleted"
It may be labeled as such, but it's been so for over 2 years now, and
op->node is used all over the place. I think Ben would like to
eventually move to using the node pointer in archdata, but that will
require a fair bit of refactoring.
Ben will kick me if I'm wrong, but I'll go out on a limb and say that
I think you're okay to use it.
>. And could I safely assume that all architectures will have the node
> entry?
All three current users do.
>> > +static struct of_device_id of_ram_match[] =3D {
>> > + =A0 =A0 =A0 { .compatible =3D "mtd-ram", },
>> > + =A0 =A0 =A0 {},
>> > +};
>> > +MODULE_DEVICE_TABLE(of, of_ram_match);
>> > +
>> > +static struct of_platform_driver of_ram_driver =3D {
>>
>> __devinitdata
>
> I assume you mean the match_table and not the of_platform_driver. Shouldn=
't it
> even better be const and using __devinitconst?
correct on both counts.
g.
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: question : DMA of PCI bridge
From: David Hawkins @ 2009-05-21 3:57 UTC (permalink / raw)
To: Sauce.Cheng; +Cc: linuxppc-dev
In-Reply-To: <23647394.post@talk.nabble.com>
Hi,
> my processor is MPC8247, on Linux 2.6.11
>
> in MPC8247 manual reference, the interrupt of DMA unit belonged PCI bridge.
> that is different from SDMA and IDMA. through i do not know what 's the
> different. heard SDMA is used to transfer between CPM and 60x. DMA is used
> to transfer between 60x bus and PCI, or 60x bus - 60x bus. i am not sure.
>
>> Whether or not you get packing bytes when you access a
>> 16-bit device and transfer the data to a 32-bit destination
>> depends on how the device is mapped. For example, a 16-bit
>> device can be implemented such that it responds to 8-bit,
>> 16-bit, and 32-bit requests, but the 32-bit requests will
>> require more wait-states, since the device has to be
>> read from twice before constructing a 32-bit word to
>> place on the PCI bus.
>
> ya, that's it
>
>> Its also possible that the DMA controller can be configured
>> to deal with different source and destination widths. However
>> without knowing what processor or DMA controller you are
>> asking about, theres not much to say.
>
> in the manual reference charpter 9.13 DMA, source and destination address
> can be configured. i can not find the hint about source and destination
> widths configured.
I won't have a chance to look at the MPC8247 manual, so
I'll just give a general comment.
If you are DMAing from an internal peripheral, then it's
width will be hard-coded and can be read from the user-manual.
If you are DMAing from a local bus then the local bus definition
should determine what happens. For example, on the MPC8349, you
can put 16-bit flash on the local bus, and configure the local
bus controller to know that it is 16-bits wide. A 32-bit access
by the CPU or DMA controller will generate two reads on the
local bus.
You can investigate to see whether the MPC8247 works similarly.
Cheers,
Dave
^ permalink raw reply
* Re: question : DMA of PCI bridge
From: Sauce.Cheng @ 2009-05-21 3:42 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4A137E4F.4040900@ovro.caltech.edu>
thank you dave for your reply
my processor is MPC8247, on Linux 2.6.11
in MPC8247 manual reference, the interrupt of DMA unit belonged PCI bridge.
that is different from SDMA and IDMA. through i do not know what 's the
different. heard SDMA is used to transfer between CPM and 60x. DMA is used
to transfer between 60x bus and PCI, or 60x bus - 60x bus. i am not sure.
> Whether or not you get packing bytes when you access a
> 16-bit device and transfer the data to a 32-bit destination
> depends on how the device is mapped. For example, a 16-bit
> device can be implemented such that it responds to 8-bit,
> 16-bit, and 32-bit requests, but the 32-bit requests will
> require more wait-states, since the device has to be
> read from twice before constructing a 32-bit word to
> place on the PCI bus.
ya, that's it
> Its also possible that the DMA controller can be configured
> to deal with different source and destination widths. However
> without knowing what processor or DMA controller you are
> asking about, theres not much to say.
in the manual reference charpter 9.13 DMA, source and destination address
can be configured. i can not find the hint about source and destination
widths configured.
--
View this message in context: http://www.nabble.com/question-%3A-DMA-of-PCI-bridge-tp23628338p23647394.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.
^ permalink raw reply
* problem in registering the device while inserting the kernel module
From: patel rajendra @ 2009-05-21 1:48 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2032 bytes --]
Hi Members of linuxppc,
I'm working on XUPV2P board with Virtex II Pro FPGA device.
I written a kernel module for LED device. I got that module run successfuly on ML403 board having Virtex 4 FPGA.I have not make any change in my source code, because I don't feel any change is required.
On XUP board when I run "insmod xilinx_led.ko" command on my target board, I got following message.
# insmod xilinx_led.ko
Oops: kernel access of bad area, sig: 11 [#1]
PREEMPT
NIP: d1006190 LR: d1006188 CTR: 00000000
REGS: c0705db0 TRAP: 0300 Not tainted (2.6.23xlnx)
MSR: 00029030 <EE,ME,IR,DR> CR: 24000024 XER: 00000000
DEAR: 0000004c, ESR: 00000000
TASK = c04c63d0[186] 'insmod' THREAD: c0704000
GPR00: d1006188 c0705e60 c04c63d0 00000000 000000d0 00000001 00000000 c0220ae0
GPR08: c006c60c 00000000 00000001 c04553f0 026f4bac 100b4260 d1003288 d1007668
GPR16: d1003288 d1003238 0000fff1 0000fff2 0000004c 00000000 d100762c c003e94c
GPR24: d1002e02 00000018 d1002000 00000019 d1000000 d1007598 d10077c8 00000000
NIP [d1006190] xilinx_ml403_led_setup+0x174/0x1dc [xilinx_led]
LR [d1006188] xilinx_ml403_led_setup+0x16c/0x1dc [xilinx_led]
Call Trace:
[c0705e60] [d1006188] xilinx_ml403_led_setup+0x16c/0x1dc [xilinx_led] (unreliable)
[c0705e90] [c0040be0] sys_init_module+0x120c/0x12f8
[c0705f40] [c0002c10] ret_from_syscall+0x0/0x3c
Instruction dump:
48000819 3d20d100 39297620 913f003c 93bf0040 3c800fc0 60840001 7fe3fb78
38a00001 48000805 813e0014 7c7f1b78 <80e9004c> 3c60d100 3c80d100 80bc77c8
Note: After above output when I execute "lsmod" command. I observed that led device is tainted.
~ # lsmod
Module Size Used by Tainted: G
xilinx_led 6172 1
~ #
What I understood from above message is that there is a problem in registering the device in function xilinx_ml403_led_setup( ).
Anyone can help me out to solve this problem?
Rajendra
Bollywood news, movie reviews, film trailers and more! Go to http://in.movies.yahoo.com/
[-- Attachment #2: Type: text/html, Size: 8766 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] maps/mtd-ram: add an of-platform driver
From: Wolfram Sang @ 2009-05-21 0:46 UTC (permalink / raw)
To: Grant Likely; +Cc: linuxppc-dev, linux-mtd, ben-linux
In-Reply-To: <fa686aa40905190757w68b35333j6f0fa84ea253a486@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 6832 bytes --]
Hello Grant,
as I am just working on V2 (fixed even some additional things), two more
questions came up:
On Tue, May 19, 2009 at 08:57:15AM -0600, Grant Likely wrote:
> On Wed, Jan 21, 2009 at 11:41 AM, Wolfram Sang <w.sang@pengutronix.de> wrote:
> > Create an of-aware driver using the now exported generic functions from
> > plat-ram.c. A typical oftree snipplet for it looks like this:
> >
> > sram@04e00000 {
> > compatible = "mtd-ram";
> > reg = <0x04e00000 0x00200000>;
> > bank-width = <2>;
> > };
> >
> > Partitions on this device are not yet supported.
>
> This is a new device tree binding. It must be documented in
> Documentation/powerpc/dts-bindings and posted to
> devicetree-discuss@ozlabs.org for review.
>
> > diff --git a/drivers/mtd/maps/Makefile b/drivers/mtd/maps/Makefile
> > index 6d9ba35..f8e3908 100644
> > --- a/drivers/mtd/maps/Makefile
> > +++ b/drivers/mtd/maps/Makefile
> > @@ -58,6 +58,7 @@ obj-$(CONFIG_MTD_WRSBC8260) += wr_sbc82xx_flash.o
> > obj-$(CONFIG_MTD_DMV182) += dmv182.o
> > obj-$(CONFIG_MTD_SHARP_SL) += sharpsl-flash.o
> > obj-$(CONFIG_MTD_PLATRAM) += plat-ram.o
> > +obj-$(CONFIG_MTD_OFRAM) += of-ram.o
> > obj-$(CONFIG_MTD_OMAP_NOR) += omap_nor.o
> > obj-$(CONFIG_MTD_INTEL_VR_NOR) += intel_vr_nor.o
> > obj-$(CONFIG_MTD_BFIN_ASYNC) += bfin-async-flash.o
> > diff --git a/drivers/mtd/maps/of-ram.c b/drivers/mtd/maps/of-ram.c
> > new file mode 100644
> > index 0000000..4d334a9
> > --- /dev/null
> > +++ b/drivers/mtd/maps/of-ram.c
> > @@ -0,0 +1,120 @@
> > +/*
> > + * drivers/mtd/maps/of-ram.c
> > + *
> > + * Generic of device based RAM map
> > + *
> > + * Copyright (C) 2009 Wolfram Sang, Pengutronix
> > + *
> > + * Using plat-ram.c by Ben Dooks
> > + *
> > + * This program is free software; you can redistribute it and/or modify it
> > + * under the terms of the GNU General Public License version 2 as published by
> > + * the Free Software Foundation.
> > + */
> > +
> > +#include <linux/module.h>
> > +#include <linux/types.h>
> > +#include <linux/init.h>
> > +#include <linux/kernel.h>
> > +#include <linux/device.h>
> > +#include <linux/platform_device.h>
> > +#include <linux/of_device.h>
> > +#include <linux/of_platform.h>
> > +#include <linux/mtd/plat-ram.h>
> > +
> > +static int of_ram_probe(struct of_device *op, const struct of_device_id *match)
>
> __devinit
>
> > +{
> > + struct platdata_mtd_ram *pdata;
> > + struct resource *resource;
> > + const char *name;
> > + const u32 *bankwidth;
> > + int ret = -ENOMEM;
> > +
> > + pdata = kzalloc(sizeof(*pdata), GFP_KERNEL);
> > + if (!pdata)
> > + goto bad0;
> > + op->dev.platform_data = pdata;
> > +
> > + name = of_get_property(op->node, "name", NULL);
> > + if (!name) {
> > + ret = -ENOENT;
> > + dev_dbg(&op->dev, "could not get node name\n");
> > + goto bad1;
> > + }
Can I just use
name = op->node->name
here? I wonder because of_device in asm/of_device.h states 'node' as "to be
obsoleted". And could I safely assume that all architectures will have the node
entry?
At least, I could drop the error check, if I understand booting-without-of
correctly? A name property will always be constructed, even if it is not
explicitly given.
> > +
> > + resource = kzalloc(sizeof(struct resource), GFP_KERNEL);
> > + if (!resource)
> > + goto bad1;
>
> Why isn't resource on the stack?
>
> > +
> > + if (of_address_to_resource(op->node, 0, resource)) {
> > + ret = -ENXIO;
> > + dev_dbg(&op->dev, "could not create resource\n");
> > + goto bad2;
> > + }
> > +
> > + bankwidth = of_get_property(op->node, "bank-width", NULL);
> > + if (*bankwidth == 0) {
> > + ret = -ENOENT;
> > + dev_dbg(&op->dev, "bank width not set\n");
> > + goto bad2;
> > + }
> > + pdata->bankwidth = *bankwidth;
> > +
> > + ret = __platram_probe(&op->dev, name, resource, pdata);
> > + kfree(resource);
> > +
> > + if (ret)
> > + goto bad1;
> > +
> > + return 0;
> > +
> > + bad2:
> > + kfree(resource);
> > + bad1:
> > + op->dev.platform_data = NULL;
> > + kfree(pdata);
> > + bad0:
> > + return ret;
>
> I'd rather see more meaningful labels. ie "err_kalloc:" and
> "err_platram_probe:".
>
> > +}
> > +
> > +static int of_ram_remove(struct of_device *op)
>
> __devexit
>
> > +{
> > + int ret;
> > + struct platdata_mtd_ram *pdata = op->dev.platform_data;
> > +
> > + ret = __platram_remove(&op->dev);
> > + op->dev.platform_data = NULL;
> > + kfree(pdata);
> > + return ret;
> > +}
> > +
> > +static struct of_device_id of_ram_match[] = {
> > + { .compatible = "mtd-ram", },
> > + {},
> > +};
> > +MODULE_DEVICE_TABLE(of, of_ram_match);
> > +
> > +static struct of_platform_driver of_ram_driver = {
>
> __devinitdata
I assume you mean the match_table and not the of_platform_driver. Shouldn't it
even better be const and using __devinitconst?
>
> > + .owner = THIS_MODULE,
> > + .name = "of-ram",
>
> This name is too generic for an of_platform device. 'mtd' needs to be
> in there somewhere.
>
> > + .match_table = of_ram_match,
> > + .probe = of_ram_probe,
> > + .remove = of_ram_remove,
>
> __devexit_p()
>
> > +};
> > +
> > +static int __init of_ram_init(void)
> > +{
> > + return of_register_platform_driver(&of_ram_driver);
> > +}
> > +
> > +static void __exit of_ram_exit(void)
> > +{
> > + of_unregister_platform_driver(&of_ram_driver);
> > +}
> > +
> > +module_init(of_ram_init);
>
> Put the module_init() statement directly after the of_ram_init() definition.
>
> > +module_exit(of_ram_exit);
> > +
> > +MODULE_AUTHOR("Wolfram Sang");
> > +MODULE_DESCRIPTION("MTD OF RAM map driver");
> > +MODULE_LICENSE("GPL v2");
> > --
> > 1.5.6.5
> >
> > _______________________________________________
> > Linuxppc-dev mailing list
> > Linuxppc-dev@ozlabs.org
> > https://ozlabs.org/mailman/listinfo/linuxppc-dev
> >
>
>
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
--
Pengutronix e.K. | Wolfram Sang |
Industrial Linux Solutions | http://www.pengutronix.de/ |
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RE: RapidIO - general questions
From: Anderson, Trevor @ 2009-05-20 23:42 UTC (permalink / raw)
To: Jan Neskudla, ext Li Yang; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <1242802800.9160.143.camel@demuxf9c>
With=20regards=20to=20your=20Oops:=20we=20sometimes=20find=20that,=20altho=
ugh=20a=20switch=20may
report=20a=20port=20being=20active,=20whenever
we=20try=20to=20discover=20what=20lies=20behind=20it,=20transfer=20errors=20=
occur=20that=20are
non-recoverable.
As=20a=20solution,=20on=20Freescale=20MPC8641D,=20we=20use=20a=20DMA=20tra=
nsfer=20to=20perform=20a
simple=20MAINT=20read=20on=20a=20new=20device,=20just=20to=20see=20if=20it=
=20responds.=20Transfer
errors=20may=20still=20happen,=20but=20they=20are=20recoverable=20in=20tha=
t=20case,=20and=20you
can=20train=20your=20code=20to=20avoid=20that=20port=20or=20try=20it=20lat=
er.=20(The=20DMA=20engine
will=20report=20the=20error,=20not=20the=20processor.)
>=20-----Original=20Message-----
>=20From:=20linuxppc-dev-bounces+tanderson=3Dcurtisswright.com@ozlabs.org
[mailto:linuxppc-dev-
>=20bounces+tanderson=3Dcurtisswright.com@ozlabs.org]=20On=20Behalf=20Of=20=
Jan
Neskudla
>=20Sent:=20Wednesday,=20May=2020,=202009=2012:00=20AM
>=20To:=20ext=20Li=20Yang
>=20Cc:=20linuxppc-dev;=20linux-kernel@vger.kernel.org
>=20Subject:=20Re:=20RapidIO=20-=20general=20questions
>=20
>=20n=20Fri,=202009-05-15=20at=2015:56=20+0800,=20ext=20Li=20Yang=20wrote:=
>=20>=20On=20Fri,=20May=2015,=202009=20at=203:33=20PM,=20Jan=20Neskudla
<jan.neskudla.ext@nsn.com>=20wrote:
>=20>=20>=20On=20Wed,=202009-05-13=20at=2018:57=20+0800,=20ext=20Li=20Yang=
=20wrote:
>=20>=20>>=20cc'ed=20LKML
>=20>=20>>
>=20>=20>>=20On=20Tue,=20May=2012,=202009=20at=205:17=20PM,=20Jan=20Neskud=
la
<jan.neskudla.ext@nsn.com>=20wrote:
>=20>=20>>=20>=20Hallo
>=20>=20>>=20>
>=20>=20>>=20>=20we'd=20likes=20to=20use=20a=20RapidIO=20as=20a=20general=20=
communication=20bus=20on
our=20new
>=20>=20>>=20>=20product,=20and=20so=20I=20have=20some=20questions=20about=
=20general=20design=20of
Linux=20RIO
>=20>=20>>=20>=20subsystem.=20I=20did=20not=20find=20any=20better=20mailin=
g=20list=20for=20RapidIO
>=20>=20>>=20>=20discussion.
>=20>=20>>=20>
>=20>=20>>=20>=20[1]=20-=20we'd=20like=20to=20implement=20following=20feat=
ures
>=20>=20>>=20>=20=20=20=20*=20Hot-plug=20(hot-insert/hot-remove)=20of=20de=
vices
>=20>=20>>=20>=20=20=20=20*=20Error=20handling=20(port-write=20packets=20-=
=20configuration,
handling=20of
>=20>=20>>=20>=20them)
>=20>=20>>=20>=20=20=20=20*=20Static=20ID=20configuration=20based=20on=20p=
ort=20numbers
>=20>=20>>=20>=20=20=20=20*=20Aux=20driver=20-=20basic=20driver,=20for=20s=
ending=20messages=20over
different
>=20>=20>>=20>=20mboxes,=20handling=20ranges=20of=20doorbells
>=20>=20>>=20>
>=20>=20>>=20>=20=20=20=20Is=20it=20here=20anyone=20who=20is=20working=20o=
n=20any=20improvement,=20or
anyone=20who
>=20>=20>>=20>=20knows=20the=20development=20plans=20for=20RapidIO=20subsy=
stem?
>=20>=20>>=20>
>=20>=20>>
>=20>=20>>=20AFAIK,=20there=20is=20no=20one=20currently=20working=20on=20t=
hese=20features=20for
Linux.
>=20>=20>>=20It=20will=20be=20good=20if=20you=20can=20add=20these=20useful=
=20features.
>=20>=20>=20Yes=20it=20looks=20like=20that,=20currently=20we=20are=20analy=
zing=20current=20rapidIO
>=20>=20>=20system,=20and=20how=20we=20can=20add=20these=20features.
>=20>=20>
>=20>=20>>
>=20>=20>>=20>=20[2]=20-=20I=20have=20a=20following=20problem=20with=20a=20=
current=20implementation
of
>=20>=20>>=20>=20loading=20drivers.=20The=20driver=20probe-function=20call=
=20is=20based=20on
comparison
>=20>=20>>=20>=20of=20VendorID=20(VID)=20and=20DeviceID=20(DID)=20only.=20=
Thus=20if=20I=20have=203
devices=20with
>=20>=20>>=20>=20same=20DID=20and=20VID=20connected=20to=20the=20same=20ne=
twork=20(bus),=20the
driver=20is
>=20>=20>>=20>=20loaded=203times,=20instead=20only=20once=20for=20the=20ac=
tual=20device=20Master
port.
>=20>=20>>
>=20>=20>>=20This=20should=20be=20the=20correct=20way=20as=20you=20actuall=
y=20have=203=20instances
of=20the=20device.
>=20>=20>>
>=20>=20>>=20>
>=20>=20>>=20>=20Rionet=20driver=20solved=20this=20by=20enabling=20to=20ca=
ll=20initialization
function
>=20>=20>>=20>=20just=20once,=20and=20it=20expect=20that=20this=20is=20the=
=20Master=20port.
>=20>=20>>
>=20>=20>>=20Rionet=20is=20kind=20of=20special.=20=20It's=20not=20working=20=
like=20a=20simple=20device
>=20>=20>>=20driver,=20but=20more=20like=20a=20customized=20protocol=20sta=
ck=20to=20support
multiple
>=20>=20>>=20ethernet=20over=20rio=20links.
>=20>=20>>
>=20>=20>>=20>
>=20>=20>>=20>=20Is=20it=20this=20correct=20behavior=20=20?=20It=20looks=20=
to=20me=20that=20RapidIO=20is
handled
>=20>=20>>=20>=20like=20a=20local=20bus=20(like=20PCI)
>=20>=20>>
>=20>=20>>=20This=20is=20correct=20behavior.=20=20All=20of=20them=20are=20=
using=20Linux
device/driver
>=20>=20>>=20infrastructure,=20but=20rionet=20is=20a=20special=20device.
>=20>=20>
>=20>=20>=20But=20I=20do=20not=20have=20a=203=20devices=20on=20one=20silic=
on.=20I=20am=20talking=20about=203
>=20>=20>=20devices=20(3=20x=20EP8548=20boards=20+=20IDT=20switch)=20conne=
cted=20over=20rapidIO
through
>=20>=20>=20the=20switch.=20And=20in=20this=20case=20I'd=20like=20to=20hav=
e=20only=20one=20driver
siting=20on
>=20>=20>=20the=20top=20of=20Linux=20RapidIO=20subsystem.=20I=20don't=20se=
e=20the=20advantage=20of
loading
>=20>
>=20>=20You=20are=20having=20one=20driver,=20but=20it=20probes=203=20times=
=20for=20each=20device
using
>=20>=20the=20driver.
>=20>
>=20>=20>=20a=20driver=20locally=20for=20remote=20device.=20Am=20I=20missi=
ng=20something=20=20?
>=20>
>=20>=20If=20you=20want=20to=20interact=20with=20the=20remote=20device,=20=
you=20need=20the=20driver
to
>=20>=20do=20the=20work=20locally.
>=20
>=20We=20are=20going=20to=20use=20a=20RapidIO=20as=20a=20bigger=20network=20=
of=20active=20devices,
and
>=20each=20will=20have=20each=20own=20driver=20(sitting=20on=20its=20own),=
=20and=20all=20the
>=20settings=20will=20be=20done=20over=20maintenance=20packets.
>=20
>=20May=20be=20it=20will=20be=20solved=20by=20the=20fact,=20that=20we=20ar=
e=20going=20to=20use=20a
>=20staticIDs,=20so=20there=20will=20be=20no=20discovery=20as=20it=20is=20=
now.=20And=20thus=20there
>=20will=20be=20only=20one=20device=20visible=20in=20the=20internal=20stru=
ctures=20of=20the
>=20subsystem,=20and=20thus=20only=20one=20drive=20will=20be=20loaded.
>=20
>=20>
>=20>=20>
>=20>=20>=20And=20one=20more=20think,=20I=20am=20getting=20so=20much=20Bus=
=20errors=20OOPSes.
Whenever
>=20>=20>=20there=20is=20a=20problem=20with=20a=20comunication=20over=20Ri=
o=20I=20get=20such=20a
kernel=20OPS.
>=20>=20>=20I=20had=20to=20add=20some=20delays=20into=20some=20function=20=
to=20be=20able=20to=20finish
the
>=20>=20>=20enum+discovery=20process.=20Did=20you=20have=20some=20experien=
ce=20with=20some
bigger
>=20>=20>=20rio=20network=20running=20under=20linux=20?
>=20>
>=20>=20It=20looks=20like=20an=20known=20issue=20for=20switched=20rio=20ne=
twork,=20but=20I=20don't
>=20>=20have=20the=20correct=20equipment=20to=20reproduce=20the=20problem=20=
here.=20=20Could=20you
>=20>=20do=20some=20basic=20debugging=20and=20share=20your=20findings?=20=20=
Thanks.
>=20
>=20I=20tried=20to=20acquired=20some=20info=20about=20the=20problem,=20I=20=
found=20that=20the=20OOPS
>=20always=20occur=20when=20there=20is=20no=20respond=20from=20the=20devic=
e=20or=20the=20respond
is
>=20too=20slow.=20I=20always=20got=20that=20error=20during=20function=20ca=
ll
>=20rio_get_host_deviceid_lock=20when=20it=20tries=20to=20access=20a=20rem=
ote=20device=20or
>=20switch.=20This=20function=20is=20the=20first=20call=20of=20the
rio_mport_read_config_32
>=20so=20is=20also=20first=20try=20of=20remote=20access=20to=20any=20devic=
e.
>=20
>=20It=20is=20a=20timing=20issue,=20and=20after=20placing=20a=20printk=20i=
nto=20the
>=20rio_get_host_deviceid_lock=20the=20OOPSing=20almost=20disappeared.
>=20
>=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=
=20=20=20=20=20=20=20=20=20Jan
>=20
>=20>
>=20>=20-=20Leo
>=20
>=20_______________________________________________
>=20Linuxppc-dev=20mailing=20list
>=20Linuxppc-dev@ozlabs.org
>=20https://ozlabs.org/mailman/listinfo/linuxppc-dev
_______________________________________________________________________
This=20e-mail=20and=20any=20files=20transmitted=20with=20it=20are=20propri=
etary=20and=20intended=20solely=20for=20the=20use=20of=20the=20individual=20=
or=20entity=20to=20whom=20they=20are=20addressed.=20If=20you=20have=20reas=
on=20to=20believe=20that=20you=20have=20received=20this=20e-mail=20in=20er=
ror,=20please=20notify=20the=20sender=20and=20destroy=20this=20email=20and=
=20any=20attached=20files.=20Please=20note=20that=20any=20views=20or=20opi=
nions=20presented=20in=20this=20e-mail=20are=20solely=20those=20of=20the=20=
author=20and=20do=20not=20necessarily=20represent=20those=20of=20the=20Cur=
tiss-Wright=20Corporation=20or=20any=20of=20its=20subsidiaries.=20=20Docum=
ents=20attached=20hereto=20may=20contain=20technology=20subject=20to=20gov=
ernment=20export=20regulations.=20Recipient=20is=20solely=20responsible=20=
for=20ensuring=20that=20any=20re-export,=20transfer=20or=20disclosure=20of=
=20this=20information=20is=20in=20accordance=20with=20applicable=20governm=
ent=20export=20regulations.=20=20The=20recipient=20should=20check=20this=20=
e-mail=20and=20any=20attachments=20for=20the=20presence=20of=20viruses.=20=
Curtiss-Wright=20Corporation=20and=20its=20subsidiaries=20accept=20no=20li=
ability=20for=20any=20damage=20caused=20by=20any=20virus=20transmitted=20b=
y=20this=20e-mail.
^ 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