Parsing a bus fault message?

Parsing a bus fault message?

[david.hagood]

I finally found my problems accessing the PPC OWBAR registers as an
endpoint (copy/paste brown paper bag bug on my part), but I still get a
bus fault trying to access the device.

The problem is that I don't know if the fault is internal to the PPC (e.g.
I don't have something in the chip set up) or if the fault is happening on
the PCIe side of things.

Are there any good how-tos on interpreting the kernel machine check error
for the PPC, that might help me know where to look for the problem?


Alternatively, can somebody see a hint in the message that I don't know
enough to pick out? At this point, my code is trying to memcpy() from the
PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is
either a) the ATMU is not accessible b) the ATMU is accessible but not
mapped (which I would have thought the ioremap call I made would have
handled) or c) the chip is not able to bus master on the PCI bus.


Machine check in kernel mode.
Caused by (from SRR1=149030): Transfer error ack signal
Oops: Machine check, sig: 7 [#1]
SMP NR_CPUS=2 EP8641A
Modules linked in: Endpoint_driver rionetlink
NIP: c0014e80 LR: f102d434 CTR: 00000200
REGS: ef05fdf0 TRAP: 0200   Not tainted  (2.6.26.2-ep1.10)
MSR: 00149030 <EE,ME,IR,DR>  CR: 24004482  XER: 00000000
TASK = ef05b310[76] 'cat' THREAD: ef05e000 CPU: 0
GPR00: 00000000 ef05fea0 ef05b310 eed06000 f14dfffc 00001000 eed05ffc
80000000
GPR08: 00000000 00000000 00001000 c0014e60 00001000 100a7264 0ffff100
00000001
GPR16: ffffffff 004005b4 007fff00 c0290000 c02f0000 ef05ff20 bfba5978
eed06000
GPR24: eed14ce0 ef02c678 eed61910 00000000 00000000 efb8d4b0 fffffffb
00001000
NIP [c0014e80] memcpy+0x20/0x9c
LR [f102d434] Endpoint_atmu_read+0x4c/0x90 [Endpoint_driver]
Call Trace:
[ef05fea0] [ef05609c] 0xef05609c (unreliable)
[ef05feb0] [c00cf2c0] read+0xd8/0x1c8
[ef05fef0] [c007ff40] vfs_read+0xcc/0x16c
[ef05ff10] [c008074c] sys_read+0x4c/0x90
[ef05ff40] [c0011174] ret_from_syscall+0x0/0x38
--- Exception: c01 at 0xff697f0
    LR = 0x10007008
Instruction dump:
4200fff0 4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028
70c00003 7ce903a6 40820054 80e40004 <85040008> 90e60004 95060008 4200fff0
---[ end trace e0620da52f69882d ]---

Re: Parsing a bus fault message?

[Ira W. Snyder]

On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hagood@gmail.com wrote:
> I finally found my problems accessing the PPC OWBAR registers as an
> endpoint (copy/paste brown paper bag bug on my part), but I still get a
> bus fault trying to access the device.
> 
> The problem is that I don't know if the fault is internal to the PPC (e.g.
> I don't have something in the chip set up) or if the fault is happening on
> the PCIe side of things.
> 
> Are there any good how-tos on interpreting the kernel machine check error
> for the PPC, that might help me know where to look for the problem?
> 
> 
> Alternatively, can somebody see a hint in the message that I don't know
> enough to pick out? At this point, my code is trying to memcpy() from the
> PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is
> either a) the ATMU is not accessible b) the ATMU is accessible but not
> mapped (which I would have thought the ioremap call I made would have
> handled) or c) the chip is not able to bus master on the PCI bus.
> 
> 
> Machine check in kernel mode.
> Caused by (from SRR1=149030): Transfer error ack signal

^^^ this is the line that contains some critical info

In the 86xx CPU manual, you should be able to find information about the
SRR1 register. Decoding the hex SRR1=0x149030 may help.

The kernel is telling you this is a TEA (transfer error acknowledge)
error. I've only seen this when I get an unhandled timeout on the local
bus. For example, a FPGA that has died in the middle of a request.

On the PCI bus, I haven't seen this error. The 83xx PCI controller is
smart enough to return 0xffffffff when reading a non-existent device.

I'm only familiar with 83xx, so I can't help too much on an 86xx board.
My best advice is: check your addresses. Make sure they're correct.

I assume that PCI on 86xx behaves similarly to 83xx. If you read from an
outbound window, your access gets translated into a PCI address and goes
onto the PCI bus. A good way of testing this is with the devmem utility
(part of busybox). It allows you to read/write any physical memory
location.

Using devmem will help you determine if the problem is in your code or
in your setup procedure.

I hope it helps,
Ira

> Oops: Machine check, sig: 7 [#1]
> SMP NR_CPUS=2 EP8641A
> Modules linked in: Endpoint_driver rionetlink
> NIP: c0014e80 LR: f102d434 CTR: 00000200
> REGS: ef05fdf0 TRAP: 0200   Not tainted  (2.6.26.2-ep1.10)
> MSR: 00149030 <EE,ME,IR,DR>  CR: 24004482  XER: 00000000
> TASK = ef05b310[76] 'cat' THREAD: ef05e000 CPU: 0
> GPR00: 00000000 ef05fea0 ef05b310 eed06000 f14dfffc 00001000 eed05ffc
> 80000000
> GPR08: 00000000 00000000 00001000 c0014e60 00001000 100a7264 0ffff100
> 00000001
> GPR16: ffffffff 004005b4 007fff00 c0290000 c02f0000 ef05ff20 bfba5978
> eed06000
> GPR24: eed14ce0 ef02c678 eed61910 00000000 00000000 efb8d4b0 fffffffb
> 00001000
> NIP [c0014e80] memcpy+0x20/0x9c
> LR [f102d434] Endpoint_atmu_read+0x4c/0x90 [Endpoint_driver]
> Call Trace:
> [ef05fea0] [ef05609c] 0xef05609c (unreliable)
> [ef05feb0] [c00cf2c0] read+0xd8/0x1c8
> [ef05fef0] [c007ff40] vfs_read+0xcc/0x16c
> [ef05ff10] [c008074c] sys_read+0x4c/0x90
> [ef05ff40] [c0011174] ret_from_syscall+0x0/0x38
> --- Exception: c01 at 0xff697f0
>     LR = 0x10007008
> Instruction dump:
> 4200fff0 4e800020 7c032040 418100a0 54a7e8ff 38c3fffc 3884fffc 41820028
> 70c00003 7ce903a6 40820054 80e40004 <85040008> 90e60004 95060008 4200fff0
> ---[ end trace e0620da52f69882d ]---
> 
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev

Re: Parsing a bus fault message?

[Scott Wood]

On Tue, 28 Sep 2010 08:31:54 -0700
"Ira W. Snyder" <iws@ovro.caltech.edu> wrote:

> On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hagood@gmail.com wrote:
> > Alternatively, can somebody see a hint in the message that I don't know
> > enough to pick out? At this point, my code is trying to memcpy() from the
> > PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is
> > either a) the ATMU is not accessible b) the ATMU is accessible but not
> > mapped (which I would have thought the ioremap call I made would have
> > handled) or c) the chip is not able to bus master on the PCI bus.

Check the LAWs, the outbound ATMU, and the PCI device's BAR.  Make sure
the address goes where you're expecting at each level.

> > Machine check in kernel mode.
> > Caused by (from SRR1=149030): Transfer error ack signal
> 
> ^^^ this is the line that contains some critical info
> 
> In the 86xx CPU manual, you should be able to find information about the
> SRR1 register. Decoding the hex SRR1=0x149030 may help.
> 
> The kernel is telling you this is a TEA (transfer error acknowledge)
> error. I've only seen this when I get an unhandled timeout on the local
> bus. For example, a FPGA that has died in the middle of a request.

I've seen it when you access a physical address that has no device
backing it up.

> On the PCI bus, I haven't seen this error. The 83xx PCI controller is
> smart enough to return 0xffffffff when reading a non-existent device.

I believe that behavior is configurable.

-Scott

Re: Parsing a bus fault message?

[tiejun.chen]

Scott Wood wrote:
> On Tue, 28 Sep 2010 08:31:54 -0700
> "Ira W. Snyder" <iws@ovro.caltech.edu> wrote:
> 
>> On Tue, Sep 28, 2010 at 09:26:51AM -0500, david.hagood@gmail.com wrote:
>>> Alternatively, can somebody see a hint in the message that I don't know
>>> enough to pick out? At this point, my code is trying to memcpy() from the
>>> PCIe bus (mapped via the outbound ATMU) to local memory, so the fault is
>>> either a) the ATMU is not accessible b) the ATMU is accessible but not
>>> mapped (which I would have thought the ioremap call I made would have
>>> handled) or c) the chip is not able to bus master on the PCI bus.
> 
> Check the LAWs, the outbound ATMU, and the PCI device's BAR.  Make sure

I also meet machine check exception if configure LAW improperly for PCI. (i.e.
unmatched PCIe controller id.)

>From you log looks 0xexxxxxxx should be your PCI space. So you can check if that
 fall into appropriate LAW configuration. Maybe you can post your boot log and
error log here.

> the address goes where you're expecting at each level.
> 
>>> Machine check in kernel mode.
>>> Caused by (from SRR1=149030): Transfer error ack signal
>> ^^^ this is the line that contains some critical info
>>
>> In the 86xx CPU manual, you should be able to find information about the
>> SRR1 register. Decoding the hex SRR1=0x149030 may help.

Actually 'Transfer error ack signal' is the result just after kernel decode
SRR1/MSSSR0.

>>
>> The kernel is telling you this is a TEA (transfer error acknowledge)
>> error. I've only seen this when I get an unhandled timeout on the local
>> bus. For example, a FPGA that has died in the middle of a request.
> 

I met this only one time when kernel access USB host controller REGs on one
mpc837x. But the same kernel is fine on another same version target. So I think
sometimes you have to check the hardware.

> I've seen it when you access a physical address that has no device
> backing it up.
>

Yes. This should be most common reason for machine check exception when we
access one address with cache inhibited.

>> On the PCI bus, I haven't seen this error. The 83xx PCI controller is
>> smart enough to return 0xffffffff when reading a non-existent device.
> 
> I believe that behavior is configurable.

I know 0xfffffffff will be returned by some PCI controller when PCI controller
access non-existent device. Because PCI controller can't get any response from
that non-existed device. So PCI controller think this 'read' should be aborted
by asserting bus to one known state, 0xffffffff. But I have to admit I really am
not sure if this is configured. I prefer to this behavior should be associated
to the given PCI controller fixed feature.

Tiejun

> 
> -Scott
> 
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
> 

Re: Parsing a bus fault message?

[david.hagood]

> Scott Wood wrote:
> I also meet machine check exception if configure LAW improperly for PCI.
> (i.e.
> unmatched PCIe controller id.)
>
> From you log looks 0xexxxxxxx should be your PCI space. So you can check
> if that
>  fall into appropriate LAW configuration. Maybe you can post your boot log
> and
> error log here.

Using EP8641A machine description
Total memory = 1024MB; using 2048kB for hash table (at cfa00000)
Linux version 2.6.26.2-ep1.10 (SRWhite@WIC-102333) (gcc version 4.0.0
(DENX ELDK 4.1 4.0.0)) #269 SMP PREEMPT Tue Sep 28 15:48:43 CDT 2010
Found initrd at 0xcfdfa000:0xcffa9663
Found legacy serial port 0 for /soc8641@e0000000/serial@4500
  mem=e0004500, taddr=e0004500, irq=0, clk=500000000, speed=0
Found legacy serial port 1 for /soc8641@e0000000/serial@4600
  mem=e0004600, taddr=e0004600, irq=0, clk=500000000, speed=0
CPU maps initialized for 1 thread per core
 (thread shift is 0)
console [udbg0] enabled
Entering add_active_range(0, 0, 262144) 0 entries of 256 used
EP8641A board from Embedded Planet
Top of RAM: 0x40000000, Total RAM: 0x40000000
Memory hole size: 0MB
Zone PFN ranges:
  DMA             0 ->   196608
  Normal     196608 ->   196608
  HighMem    196608 ->   262144
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->   262144
On node 0 totalpages: 262144
  DMA zone: 1536 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 195072 pages, LIFO batch:31
  Normal zone: 0 pages used for memmap
  HighMem zone: 512 pages used for memmap
  HighMem zone: 65024 pages, LIFO batch:15
  Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
Kernel command line: root=/dev/ram rw console=ttyS0,115200
ip=10.200.120.158:::255.255.0.0::eth0
mtdparts=physmap-flash.0:0x1300000(linux)ro,0x6bc0000(jffs),-(rsvd)ro
mpic: Setting up MPIC " MPIC     " version 1.2 at e0040000, max 2 CPUs
mpic: ISU size: 16, shift: 4, mask: f
mpic: Initializing for 80 sources
PID hash table entries: 4096 (order: 12, 16384 bytes)
time_init: decrementer frequency = 125.000000 MHz
time_init: processor frequency   = 1500.000000 MHz
clocksource: timebase mult[2000000] shift[22] registered
clockevent: decrementer mult[2000] shift[16] cpu[0]
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
High memory: 262144k
Memory: 1031248k/1048576k available (3064k kernel code, 16476k reserved,
84k data, 149k bss, 164k init)
Calibrating delay loop... 249.85 BogoMIPS (lpj=499712)
Mount-cache hash table entries: 512
mpic: requesting IPIs ...
Processor 1 found.
Synchronizing timebase
Got ack
score 299, offset 1000
score 299, offset 500
score 299, offset 250
score 299, offset 125
score 299, offset 62
score 297, offset 31
score -299, offset 15
score 297, offset 23
score 253, offset 19
score -299, offset 17
score -269, offset 18
Min 18 (score -269), Max 19 (score 253)
Final offset: 19 (269/300)
clockevent: decrementer mult[2000] shift[16] cpu[1]
Brought up 2 CPUs
net_namespace: 208 bytes
NET: Registered protocol family 16
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs...it isn't (no cpio magic); looks like an
initrd
Freeing initrd memory: 1725k freed
setup_kcore: restrict size=3fffffff
of-fsl-dma e0021300.dma: Probe the Freescale DMA driver for
fsl,eloplus-dma controller at e0021300...
of-fsl-dma-channel e0021100.dma-channe: #0 (fsl,eloplus-dma-channel), irq 20
of-fsl-dma-channel e0021180.dma-channe: #1 (fsl,eloplus-dma-channel), irq 21
of-fsl-dma-channel e0021200.dma-channe: #2 (fsl,eloplus-dma-channel), irq 22
of-fsl-dma-channel e0021280.dma-channe: #3 (fsl,eloplus-dma-channel), irq 23
Setting up RapidIO peer-to-peer network /rapidio@e00c0000
fsl-of-rio e00c0000.rapidio: Of-device full name /rapidio@e00c0000
fsl-of-rio e00c0000.rapidio: Regs start 0xe00c0000 size 0x20000
fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
0x0000000020000000.
fsl-of-rio e00c0000.rapidio: bellirq: 50, txirq: 53, rxirq 54
fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial
fsl-of-rio e00c0000.rapidio: Hardware port width: 4
fsl-of-rio e00c0000.rapidio: Training connection status: Four-lane
fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256
highmem bounce pool size: 64 pages
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
msgmni has been set to 1507
io scheduler noop registered (default)
Generic RTC Driver v1.07
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 28) is a 16550A
brd: module loaded
loop: module loaded
Gianfar MII Bus: probed
eth0: Gianfar Ethernet Controller Version 1.2, 00:10:ec:01:1a:d3
eth0: Running with NAPI enabled
eth0: 256/256 RX/TX BD ring size
eth1: Gianfar Ethernet Controller Version 1.2, 00:10:ec:81:1a:d3
eth1: Running with NAPI enabled
eth1: 256/256 RX/TX BD ring size
eth2: Gianfar Ethernet Controller Version 1.2, 00:10:ec:41:1a:d3
eth2: Running with NAPI enabled
eth2: 256/256 RX/TX BD ring size
eth3: Gianfar Ethernet Controller Version 1.2, 00:10:ec:c1:1a:d3
eth3: Running with NAPI enabled
eth3: 256/256 RX/TX BD ring size
physmap platform flash device: 08000000 at f8000000
physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
physmap-flash.0: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
3 cmdlinepart partitions found on MTD device physmap-flash.0
Creating 3 MTD partitions on "physmap-flash.0":
0x00000000-0x01300000 : "linux"
0x01300000-0x07ec0000 : "jffs"
0x07ec0000-0x08000000 : "rsvd"
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
IP-Config: Complete:
     device=eth0, addr=10.200.120.158, mask=255.255.0.0, gw=255.255.255.255,
     host=10.200.120.158, domain=, nis-domain=(none),
     bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
RAMDISK: Compressed image found at block 0
VFS: Mounted root (ext2 filesystem).
Freeing unused kernel memory: 164k init
PHY: e0024520:10 - Link is Up - 100/Full
RIO: discover master port 0, RIO0 mport
rionetlink_init: receive handler registration suceeded!!!!
rionetlink_init: rio_register_driver suceeded!!!!

Besides, in my setup, there are 2 LAWS programmed to point at the PEX: one
mapping A0000000 to BFFFFFFF to the PEX, and one mapping  E2000000 to
E2FFFFFF. My code directly scans the LAWS and picks the first one it sees
mapped to the PEX, so it is picking A00000000, and using that. Is there an
issue with having 2 LAWs mapping the same device to different locations?


Being unfortunately a man of many hats, I haven't had a lot of time today
to work on this particular fire. Hopefully in the next couple of days I
can get some more time to look into it more.

I do thank all of you for the pointers, and I'll look into them.

(BTW: Anybody near Wichita, and want to earn some extra $$$ helping me out?)

Re: Parsing a bus fault message?

[tiejun.chen]

david.hagood@gmail.com wrote:
>> Scott Wood wrote:
>> I also meet machine check exception if configure LAW improperly for PCI.
>> (i.e.
>> unmatched PCIe controller id.)
>>
>> From you log looks 0xexxxxxxx should be your PCI space. So you can check
>> if that
>>  fall into appropriate LAW configuration. Maybe you can post your boot log
>> and
>> error log here.
> 
> Using EP8641A machine description
> Total memory = 1024MB; using 2048kB for hash table (at cfa00000)
> Linux version 2.6.26.2-ep1.10 (SRWhite@WIC-102333) (gcc version 4.0.0
> (DENX ELDK 4.1 4.0.0)) #269 SMP PREEMPT Tue Sep 28 15:48:43 CDT 2010
> Found initrd at 0xcfdfa000:0xcffa9663
> Found legacy serial port 0 for /soc8641@e0000000/serial@4500
>   mem=e0004500, taddr=e0004500, irq=0, clk=500000000, speed=0
> Found legacy serial port 1 for /soc8641@e0000000/serial@4600
>   mem=e0004600, taddr=e0004600, irq=0, clk=500000000, speed=0
> CPU maps initialized for 1 thread per core
>  (thread shift is 0)
> console [udbg0] enabled
> Entering add_active_range(0, 0, 262144) 0 entries of 256 used
> EP8641A board from Embedded Planet
> Top of RAM: 0x40000000, Total RAM: 0x40000000
> Memory hole size: 0MB
> Zone PFN ranges:
>   DMA             0 ->   196608
>   Normal     196608 ->   196608
>   HighMem    196608 ->   262144
> Movable zone start PFN for each node
> early_node_map[1] active PFN ranges
>     0:        0 ->   262144
> On node 0 totalpages: 262144
>   DMA zone: 1536 pages used for memmap
>   DMA zone: 0 pages reserved
>   DMA zone: 195072 pages, LIFO batch:31
>   Normal zone: 0 pages used for memmap
>   HighMem zone: 512 pages used for memmap
>   HighMem zone: 65024 pages, LIFO batch:15
>   Movable zone: 0 pages used for memmap
> Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 260096
> Kernel command line: root=/dev/ram rw console=ttyS0,115200
> ip=10.200.120.158:::255.255.0.0::eth0
> mtdparts=physmap-flash.0:0x1300000(linux)ro,0x6bc0000(jffs),-(rsvd)ro
> mpic: Setting up MPIC " MPIC     " version 1.2 at e0040000, max 2 CPUs
> mpic: ISU size: 16, shift: 4, mask: f
> mpic: Initializing for 80 sources
> PID hash table entries: 4096 (order: 12, 16384 bytes)
> time_init: decrementer frequency = 125.000000 MHz
> time_init: processor frequency   = 1500.000000 MHz
> clocksource: timebase mult[2000000] shift[22] registered
> clockevent: decrementer mult[2000] shift[16] cpu[0]
> Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
> Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
> High memory: 262144k
> Memory: 1031248k/1048576k available (3064k kernel code, 16476k reserved,
> 84k data, 149k bss, 164k init)
> Calibrating delay loop... 249.85 BogoMIPS (lpj=499712)
> Mount-cache hash table entries: 512
> mpic: requesting IPIs ...
> Processor 1 found.
> Synchronizing timebase
> Got ack
> score 299, offset 1000
> score 299, offset 500
> score 299, offset 250
> score 299, offset 125
> score 299, offset 62
> score 297, offset 31
> score -299, offset 15
> score 297, offset 23
> score 253, offset 19
> score -299, offset 17
> score -269, offset 18
> Min 18 (score -269), Max 19 (score 253)
> Final offset: 19 (269/300)
> clockevent: decrementer mult[2000] shift[16] cpu[1]
> Brought up 2 CPUs
> net_namespace: 208 bytes
> NET: Registered protocol family 16
> NET: Registered protocol family 2
> IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
> TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
> TCP bind hash table entries: 65536 (order: 7, 786432 bytes)
> TCP: Hash tables configured (established 131072 bind 65536)
> TCP reno registered
> NET: Registered protocol family 1
> checking if image is initramfs...it isn't (no cpio magic); looks like an
> initrd
> Freeing initrd memory: 1725k freed
> setup_kcore: restrict size=3fffffff
> of-fsl-dma e0021300.dma: Probe the Freescale DMA driver for
> fsl,eloplus-dma controller at e0021300...
> of-fsl-dma-channel e0021100.dma-channe: #0 (fsl,eloplus-dma-channel), irq 20
> of-fsl-dma-channel e0021180.dma-channe: #1 (fsl,eloplus-dma-channel), irq 21
> of-fsl-dma-channel e0021200.dma-channe: #2 (fsl,eloplus-dma-channel), irq 22
> of-fsl-dma-channel e0021280.dma-channe: #3 (fsl,eloplus-dma-channel), irq 23
> Setting up RapidIO peer-to-peer network /rapidio@e00c0000
> fsl-of-rio e00c0000.rapidio: Of-device full name /rapidio@e00c0000
> fsl-of-rio e00c0000.rapidio: Regs start 0xe00c0000 size 0x20000
> fsl-of-rio e00c0000.rapidio: LAW start 0x00000000c0000000, size
> 0x0000000020000000.
> fsl-of-rio e00c0000.rapidio: bellirq: 50, txirq: 53, rxirq 54
> fsl-of-rio e00c0000.rapidio: RapidIO PHY type: serial
> fsl-of-rio e00c0000.rapidio: Hardware port width: 4
> fsl-of-rio e00c0000.rapidio: Training connection status: Four-lane
> fsl-of-rio e00c0000.rapidio: RapidIO Common Transport System size: 256
> highmem bounce pool size: 64 pages
> Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
> JFFS2 version 2.2. (NAND) � 2001-2006 Red Hat, Inc.
> msgmni has been set to 1507
> io scheduler noop registered (default)
> Generic RTC Driver v1.07
> Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled
> serial8250.0: ttyS0 at MMIO 0xe0004500 (irq = 42) is a 16550A
> console handover: boot [udbg0] -> real [ttyS0]
> serial8250.0: ttyS1 at MMIO 0xe0004600 (irq = 28) is a 16550A
> brd: module loaded
> loop: module loaded
> Gianfar MII Bus: probed
> eth0: Gianfar Ethernet Controller Version 1.2, 00:10:ec:01:1a:d3
> eth0: Running with NAPI enabled
> eth0: 256/256 RX/TX BD ring size
> eth1: Gianfar Ethernet Controller Version 1.2, 00:10:ec:81:1a:d3
> eth1: Running with NAPI enabled
> eth1: 256/256 RX/TX BD ring size
> eth2: Gianfar Ethernet Controller Version 1.2, 00:10:ec:41:1a:d3
> eth2: Running with NAPI enabled
> eth2: 256/256 RX/TX BD ring size
> eth3: Gianfar Ethernet Controller Version 1.2, 00:10:ec:c1:1a:d3
> eth3: Running with NAPI enabled
> eth3: 256/256 RX/TX BD ring size
> physmap platform flash device: 08000000 at f8000000
> physmap-flash.0: Found 2 x16 devices at 0x0 in 32-bit bank
>  Amd/Fujitsu Extended Query Table at 0x0040
> physmap-flash.0: CFI does not contain boot bank location. Assuming top.
> number of CFI chips: 1
> cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
> 3 cmdlinepart partitions found on MTD device physmap-flash.0
> Creating 3 MTD partitions on "physmap-flash.0":
> 0x00000000-0x01300000 : "linux"
> 0x01300000-0x07ec0000 : "jffs"
> 0x07ec0000-0x08000000 : "rsvd"
> TCP cubic registered
> NET: Registered protocol family 17
> RPC: Registered udp transport module.
> RPC: Registered tcp transport module.
> IP-Config: Complete:
>      device=eth0, addr=10.200.120.158, mask=255.255.0.0, gw=255.255.255.255,
>      host=10.200.120.158, domain=, nis-domain=(none),
>      bootserver=255.255.255.255, rootserver=255.255.255.255, rootpath=
> RAMDISK: Compressed image found at block 0
> VFS: Mounted root (ext2 filesystem).
> Freeing unused kernel memory: 164k init
> PHY: e0024520:10 - Link is Up - 100/Full
> RIO: discover master port 0, RIO0 mport
> rionetlink_init: receive handler registration suceeded!!!!
> rionetlink_init: rio_register_driver suceeded!!!!
> 
> Besides, in my setup, there are 2 LAWS programmed to point at the PEX: one
> mapping A0000000 to BFFFFFFF to the PEX, and one mapping  E2000000 to
> E2FFFFFF. My code directly scans the LAWS and picks the first one it sees
> mapped to the PEX, so it is picking A00000000, and using that. Is there an
> issue with having 2 LAWs mapping the same device to different locations?
> 

I think it should be allowed to use two LAWs to map different space for PCIe
since I ever saw more one LAWs are created for different RAM space.

Sorry for this delay response.

-Tiejun

> 
> Being unfortunately a man of many hats, I haven't had a lot of time today
> to work on this particular fire. Hopefully in the next couple of days I
> can get some more time to look into it more.
> 
> I do thank all of you for the pointers, and I'll look into them.
> 
> (BTW: Anybody near Wichita, and want to earn some extra $$$ helping me out?)
> 
> 
> 

Re: Parsing a bus fault message?

[David Hagood]

On Fri, 2010-10-08 at 17:22 +0800, tiejun.chen wrote:
> 
> I think it should be allowed to use two LAWs to map different space for PCIe
> since I ever saw more one LAWs are created for different RAM space.
> 
> Sorry for this delay response.
> 
> -Tiejun

It's my bad, as I'd worked out the problem: the host root complex had to
be forced to rescan the device and enable bus mastering on that side of
things. Once that happened, I could access PCI space.

I should have posted my success.