* Some problem about code reading
From: enorm @ 2006-08-30 13:45 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
Hi,
I met some problems when reading sourcecode of u-boot 1.1.4 (for mpc85xx)
file /cpu/mpc85xx/start.s line 276
276. #if (CFG_CCSRBAR_DEFAULT != CFG_CCSRBAR)
277. /* Special sequence needed to update CCSRBAR itself */
278. lis r4, CFG_CCSRBAR_DEFAULT@h
279. ori r4, r4, CFG_CCSRBAR_DEFAULT@l
280.
281. lis r5, CFG_CCSRBAR@h
282. ori r5, r5, CFG_CCSRBAR@l
283. srwi r6,r5,12
284. stw r6, 0(r4)
285. isync
286.
287. lis r5, 0xffff
288. ori r5,r5,0xf000
289. lwz r5, 0(r5)
290. isync
291.
292. lis r3, CFG_CCSRBAR@h
293. lwz r5, CFG_CCSRBAR@l(r3)
294. isync
295. #endif
I think it means if we don't use default CCSRBAR, we put the CCSRBAR addr actually used to the proper place in default CCSRBAR, so that it can jump to the addr we want to automatically.(line 276-286).
But, I don't know what line 287-294 does. Can some one tell me pls?
Thanks for your help.
[-- Attachment #2: Type: text/html, Size: 2538 bytes --]
^ permalink raw reply
* Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
From: Milton Miller @ 2006-08-30 14:24 UTC (permalink / raw)
To: Marcus Comstedt; +Cc: linuxppc-dev
In-Reply-To: <9mz9np82b.fsf@omoikane.mc.pp.se>
On Aug 30, 2006, at 7:04 AM, Marcus Comstedt wrote:
> "Gerhard Pircher" <gerhard_pircher at gmx.net> writes:
>> I guess this message should also be forwarded to
>> linux-usb-devel at lists.sourceforge.net. I hope the developers there
>> can make some comments.
>
> Well, I figured the first thing to do would be to reach a consensus
> here on whether or not atomic_t:s in DMA memory should be ruled as
> unallowed. Judging from the massive silence, there doesn't seem to be
> any strong opinions either way though...
I think its a case of the people that know the architecture agree
that atomics and DMA do not mix, and that this is an issue for
usb-devel to fix.
The other question is: does the current access polute the cache by
reading things where the device is supposed to be writing?
I think some on that list are familiar with the issues for incoherent
DMA, as some of the other usb drivers have been cleaned up in that
regard.
My suggestion is take the issue over there, and only cc us here if
you get pushback over there.
milton
^ permalink raw reply
* RE: Some problem about code reading
From: Wang Haiying-r54964 @ 2006-08-30 15:05 UTC (permalink / raw)
To: enorm, linuxppc-embedded
In-Reply-To: <002f01c6cc3a$a0788420$a309a8c0@SZD823>
[-- Attachment #1: Type: text/plain, Size: 2191 bytes --]
Hi,
please read the following from MPC85xx UM about the sequence on how to
write CCSRBAR:
*************************************
When the e500 core is writing to CCSRBAR, it should use the following
sequence:
- Read the current value of CCSRBAR using a load word instruction
followed by an
isync. This forces all accesses to configuration space to complete.
- Write the new value to CCSRBAR.
- Perform a load of an address that does not access configuration space
or the on-chip
SRAM, but has an address mapping already in effect (for example, boot
ROM).
Follow this load with an isync.
- Read the contents of CCSRBAR from its new location, followed by
another isync
instruction.
****************************************
The codes between line 287-294 complete the third step above.
Haiying
________________________________
From:
linuxppc-embedded-bounces+haiying.wang=freescale.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+haiying.wang=freescale.com@ozlabs.org]
On Behalf Of enorm
Sent: Wednesday, August 30, 2006 9:46 AM
To: linuxppc-embedded@ozlabs.org
Subject: Some problem about code reading
Hi,
I met some problems when reading sourcecode of u-boot 1.1.4
(for mpc85xx)
file /cpu/mpc85xx/start.s line 276
276. #if (CFG_CCSRBAR_DEFAULT != CFG_CCSRBAR)
277. /* Special sequence needed to update CCSRBAR itself */
278. lis r4, CFG_CCSRBAR_DEFAULT@h
279. ori r4, r4, CFG_CCSRBAR_DEFAULT@l
280.
281. lis r5, CFG_CCSRBAR@h
282. ori r5, r5, CFG_CCSRBAR@l
283. srwi r6,r5,12
284. stw r6, 0(r4)
285. isync
286.
287. lis r5, 0xffff
288. ori r5,r5,0xf000
289. lwz r5, 0(r5)
290. isync
291.
292. lis r3, CFG_CCSRBAR@h
293. lwz r5, CFG_CCSRBAR@l(r3)
294. isync
295. #endif
I think it means if we don't use default CCSRBAR, we put the
CCSRBAR addr actually used to the proper place in default CCSRBAR, so
that it can jump to the addr we want to automatically.(line 276-286).
But, I don't know what line 287-294 does. Can some one tell me
pls?
Thanks for your help.
[-- Attachment #2: Type: text/html, Size: 6292 bytes --]
^ permalink raw reply
* Re: undefined reference to pci_io_base
From: Geoff Levand @ 2006-08-30 15:05 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17652.55334.554969.284398@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
> Geoff Levand writes:
>
>> I found the same, but was thinking
>>
>> #if defined(CONFIG_ISA) && !defined(__mc68000__)
>>
>> So it is only built when CONFIG_ISA=y. Is there any
>> reason to always have it whit PCI?
>
> It's occasionally useful with PCI && !ISA. It's pretty useless with
> !PCI && !ISA.
>
>> Paul, can I send you that fix, or should I send it to
>> someone else?
>
> Send it to Andrew Morton.
For anyone interested, I sent that out here:
http://lkml.org/lkml/2006/8/29/374
-Geoff
^ permalink raw reply
* Driver for OCP Driver for PPC405
From: akhilesh @ 2006-08-30 16:12 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I need a OCP IDE driver for IBM PPC405 redwood6 platform for 2.6 kernel.
Any pointer for same or similar driver would be highly appreciated.
regards,
Akhilesh
^ permalink raw reply
* Re: PCIe enhanced configuration mechanism support on ppc arch
From: Milton Miller @ 2006-08-30 16:30 UTC (permalink / raw)
To: Shawn Jin; +Cc: linuxppc-dev
On Fri Aug 18 05:01:48 EST 2006, Shawn Jin wrote:
> I'm trying to find out if the current PCI subsystem supports the PCIe
> enhanced configuration mechanism, in particular, on the ppc/powerpc
> arch, which is basically a MMIO access with the address containing all
> bus, device, function, and offset info.
If what you are really trying to find is the 4k extended config space,
then there are some platforms that support that on some slots.
If you are trying to find the mmio address for your adapter, then the
answer is I am not aware of any PowerPC platforms that provide that,
although I am not familiar with the embedded processor platforms nor
the pci express Apple boxes.
> Could someone here give an authoritative answer? Or point me to
> somewhere I can look for it by myself, such as which file or directory
> in the kernel tree. I searched at arch/ppc/kernel,
> arch/powerpc/kernel, and drivers/pci but couldn't find an answer. :(
The config access support is in arch/powerpc/kernel/rtas_pci.c,
the setting of pci_ext_config_space is at arch/powerpc/kernel/pci_dn.c.
milton
^ permalink raw reply
* Re: IPSec kernel oops on ppc64
From: Joy Latten @ 2006-08-30 16:36 UTC (permalink / raw)
To: anton, herbert, linuxppc-dev, paulus; +Cc: jmorris, gcwilson, davem, netdev
>--
>diff --git a/arch/powerpc/lib/memcpy_64.S b/arch/powerpc/lib/memcpy_64.S
>index fd66acf..9e8d9e7 100644
>--- a/arch/powerpc/lib/memcpy_64.S
>+++ b/arch/powerpc/lib/memcpy_64.S
>@@ -11,6 +11,7 @@ #include <asm/ppc_asm.h>
>
> .align 7
> _GLOBAL(memcpy)
>+ std r3,-8(r1)
> mtcrf 0x01,r5
> cmpldi cr1,r5,16
> neg r6,r3 # LS 3 bits = # bytes to 8-byte dest bdry
>@@ -53,7 +54,8 @@ _GLOBAL(memcpy)
> 2: bf cr7*4+3,3f
> rotldi r9,r9,8
> stb r9,0(r3)
>-3: blr
>+3: ld r3,-8(r1)
>+ blr
>
> .Lsrc_unaligned:
> srdi r6,r5,3
>@@ -167,4 +169,5 @@ _GLOBAL(memcpy)
> 3: bf cr7*4+3,4f
> lbz r0,0(r4)
> stb r0,0(r3)
>-4: blr
>+4: ld r3,-8(r1)
>+ blr
Hi,
I tried the patch on the following:
linux-2.6.17 + patch-2.6.18-rc1
The good news is that the pings worked great!
So perhaps ESP is working ok with ICMP.
But when I tried to do sftp, I still got the oops.
I don't think TCP and ESP are working.
I pasted below info as well as the disassembled routine,
just in case.
Regards,
Joy
====================================================================
root@hvracer1 jml]# sftp joy-hv4
Connecting to joy-hv4...
kernel BUG in skb_to_sgvec at net/xfrm/xfrm_algo.c:611!
cpu 0x0: Vector: 700 (Program Check) at [c00000000257b280]
pc: c000000000305ea4: .skb_to_sgvec+0x288/0x2ec
lr: d0000000006305f0: .esp_output+0x350/0x4e4 [esp4]
sp: c00000000257b500
msr: 8000000000029032
current = 0xc000000042320b00
paca = 0xc000000000414380
pid = 2007, comm = ssh
kernel BUG in skb_to_sgvec at net/xfrm/xfrm_algo.c:611!
enter ? for help
0:mon> t
[c00000000257b5d0] d0000000006305f0 .esp_output+0x350/0x4e4 [esp4]
[c00000000257b6b0] c0000000002fe758 .xfrm4_output_finish2+0x2bc/0x3d8
[c00000000257b750] c0000000002fea28 .xfrm4_output+0x74/0x88
[c00000000257b7d0] c0000000002c1504 .ip_queue_xmit+0x474/0x50c
[c00000000257b8c0] c0000000002d4a88 .tcp_transmit_skb+0x818/0x884
[c00000000257b970] c0000000002d7c7c .tcp_connect+0x318/0x3bc
[c00000000257ba10] c0000000002dc228 .tcp_v4_connect+0x4dc/0x674
[c00000000257bb80] c0000000002ea6a0 .inet_stream_connect+0x10c/0x358
[c00000000257bc60] c000000000283fd0 .sys_connect+0xd8/0x120
[c00000000257bd90] c0000000002a4c54 .compat_sys_socketcall+0xdc/0x214
[c00000000257be30] c00000000000871c syscall_exit+0x0/0x40
--- Exception: c00 (System Call) at 0000000007a9f8fc
SP (ff88f230) is in userspace
0:mon> r
R00 = 0000000000000058 R16 = 00000000080704d8
R01 = c00000000257b500 R17 = 0000000008065d68
R02 = c0000000005261d0 R18 = 00000000ff88f2dc
R03 = c000000041da2d00 R19 = 0000000000000001
R04 = c00000003d8a9660 R20 = c00000000257bcd8
R05 = 0000000000000028 R21 = 0000000000000000
R06 = 000000000000023c R22 = 0000000000000001
R07 = c000000000660208 R23 = 0000000000000010
R08 = 00000000000041da R24 = 0000000000000001
R09 = 0000000000000000 R25 = c00000003d8a9660
R10 = 0000000000000028 R26 = 0000000000000050
R11 = 0000000000107680 R27 = 0000000000000050
R12 = d0000000006312f8 R28 = 0000000000000008
R13 = c000000000414380 R29 = 0000000000000000
R14 = 0000000000000000 R30 = c0000000004c09a8
R15 = 000000000806379c R31 = c0000000329221a0
pc = c000000000305ea4 .skb_to_sgvec+0x288/0x2ec
lr = d0000000006305f0 .esp_output+0x350/0x4e4 [esp4]
msr = 8000000000029032 cr = 28000442
ctr = c000000000305c1c xer = 0000000000000000 trap = 700
0:mon> S
msr = 8000000000001032 sprg0= 0000000000000000
pvr = 00000000003a0202 sprg1= c000000000414380
dec = 00000000f2fd7ff0 sprg2= c000000000414380
sp = c00000000257ab10 sprg3= c000000000414380
toc = c0000000005261d0 dar = 00000000ff88dfb0
0:mon> u
SLB contents of cpu 0
00 c000000008000000 0000408f92c94500
01 d000000008000000 0000f09b89af5400
02 c000000078000000 000045cb97751500
03 0000000010000000 000036ab4f98cc80
04 0000000000000000 0000f41e71baac80
05 00000000f0000000 0000ff55e973fc80
06 0000000040000000 0000f71c2b416c80
07 0000000010000000 0000f4dde01c5c80
08 c000000040000000 0000438d4c500500
09 0000000000000000 000004abd053cc80
10 00000000f0000000 00000fe3480d1c80
11 0000000040000000 000007a989da8c80
12 0000000010000000 0000056b3eb57c80
13 0000000000000000 0000f41e71baac80
14 00000000f0000000 0000ff55e973fc80
15 0000000040000000 0000f71c2b416c80
16 c000000038000000 000042cdddee5500
17 0000000010000000 0000f4dde01c5c80
18 0000000000000000 000004abd053cc80
19 00000000f0000000 00000fe3480d1c80
20 0000000040000000 000007a989da8c80
21 0000000010000000 0000056b3eb57c80
22 c000000070000000 000045cb97751500
23 0000000000000000 00008110f15afc80
24 00000000f0000000 00008c4869144c80
25 0000000040000000 0000840eaae1bc80
26 0000000000000000 0000cc36017edc80
27 00000000f0000000 0000d76d79382c80
28 0000000040000000 0000cf33bb059c80
29 0000000000000000 00008110f15afc80
30 00000000f0000000 00008c4869144c80
31 0000000040000000 0000840eaae1bc80
32 c000000040000000 0000438d4c500500
33 0000000000000000 0000cc36017edc80
34 00000000f0000000 0000d76d79382c80
35 0000000040000000 0000cf33bb059c80
36 c000000070000000 000045cb97751500
37 c000000048000000 0000438d4c500500
38 0000000008000000 000004abd053cc80
39 00000000f8000000 00000fe3480d1c80
40 0000000048000000 000007a989da8c80
41 0000000000000000 0000f41e71baac80
42 00000000f0000000 0000ff55e973fc80
43 0000000040000000 0000f71c2b416c80
44 0000000010000000 0000f4dde01c5c80
45 0000000000000000 000035ebe1371c80
46 00000000f0000000 0000412358f06c80
47 0000000040000000 000038e99abddc80
48 0000000010000000 000036ab4f98cc80
49 0000000000000000 0000f41e71baac80
50 00000000f0000000 0000ff55e973fc80
51 0000000040000000 0000f71c2b416c80
52 0000000010000000 0000f4dde01c5c80
53 0000000000000000 000035ebe1371c80
54 00000000f0000000 0000412358f06c80
55 0000000040000000 000038e99abddc80
56 0000000010000000 000036ab4f98cc80
57 0000000000000000 00006e61b00bfc80
58 00000000f0000000 0000799927c54c80
59 0000000040000000 0000715f6992bc80
60 0000000010000000 00006f211e6dac80
61 0000000000000000 000035ebe1371c80
62 00000000f0000000 0000412358f06c80
63 0000000040000000 000038e99abddc80
0:mon> e
cpu 0x0: Vector: 700 (Program Check) at [c00000000257b280]
pc: c000000000305ea4: .skb_to_sgvec+0x288/0x2ec
lr: d0000000006305f0: .esp_output+0x350/0x4e4 [esp4]
sp: c00000000257b500
msr: 8000000000029032
current = 0xc000000042320b00
paca = 0xc000000000414380
pid = 2007, comm = ssh
kernel BUG in skb_to_sgvec at net/xfrm/xfrm_algo.c:611!
0:mon>
=============================================================================
0000000000000120 <.skb_to_sgvec>:
120: 7c 08 02 a6 mflr r0
124: fa a1 ff a8 std r21,-88(r1)
128: fb 21 ff c8 std r25,-56(r1)
12c: fb 61 ff d8 std r27,-40(r1)
130: fb 81 ff e0 std r28,-32(r1)
134: fb c1 ff f0 std r30,-16(r1)
138: fb e1 ff f8 std r31,-8(r1)
13c: fa c1 ff b0 std r22,-80(r1)
140: fa e1 ff b8 std r23,-72(r1)
144: fb 01 ff c0 std r24,-64(r1)
148: fb 41 ff d0 std r26,-48(r1)
14c: fb a1 ff e8 std r29,-24(r1)
150: f8 01 00 10 std r0,16(r1)
154: f8 21 ff 31 stdu r1,-208(r1)
158: eb c2 00 00 ld r30,0(r2)
15c: 7c 7f 1b 78 mr r31,r3
160: 7c 99 23 78 mr r25,r4
164: 7c bb 2b 78 mr r27,r5
168: 7c dc 33 78 mr r28,r6
16c: 3a a0 00 00 li r21,0
170: 80 1f 00 88 lwz r0,136(r31)
174: 81 3f 00 8c lwz r9,140(r31)
178: 3b 00 00 00 li r24,0
17c: 7c 09 00 50 subf r0,r9,r0
180: 7c 1a 07 b4 extsw r26,r0
184: 7c 1b d0 50 subf r0,r27,r26
188: 7c 00 07 b4 extsw r0,r0
18c: 2f 80 00 00 cmpwi cr7,r0,0
190: 40 9d 00 a4 ble- cr7,234 <.skb_to_sgvec+0x114>
194: 7f 9c 00 00 cmpw cr7,r28,r0
198: 7f 8a e3 78 mr r10,r28
19c: 40 9d 00 08 ble- cr7,1a4 <.skb_to_sgvec+0x84>
1a0: 7c 0a 03 78 mr r10,r0
1a4: e8 1f 00 d8 ld r0,216(r31)
1a8: 3d 20 40 00 lis r9,16384
1ac: e9 7e 80 18 ld r11,-32744(r30)
1b0: 7d 4a 07 b4 extsw r10,r10
1b4: 38 e0 00 00 li r7,0
1b8: 79 29 07 c6 rldicr r9,r9,32,31
1bc: 7c 1b 02 14 add r0,r27,r0
1c0: 7c 00 4a 14 add r0,r0,r9
1c4: 78 09 d9 60 rldicl r9,r0,27,37
1c8: 78 08 84 02 rldicl r8,r0,48,16
1cc: 78 00 46 02 rldicl r0,r0,40,24
1d0: 79 29 1f 24 rldicr r9,r9,3,60
1d4: 7d 29 58 2a ldx r9,r9,r11
1d8: 2f a9 00 00 cmpdi cr7,r9,0
1dc: 41 9e 00 0c beq- cr7,1e8 <.skb_to_sgvec+0xc8>
1e0: 78 00 1c 28 rldic r0,r0,3,48
1e4: 7c e9 02 14 add r7,r9,r0
1e8: e8 07 00 00 ld r0,0(r7)
1ec: 79 0b 36 64 rldicr r11,r8,6,57
1f0: 7d 2a e0 50 subf r9,r10,r28
1f4: 7d 3c 07 b4 extsw r28,r9
1f8: 78 00 07 64 rldicr r0,r0,0,61
1fc: 2f bc 00 00 cmpdi cr7,r28,0
200: 7c 00 5a 14 add r0,r0,r11
204: f8 19 00 00 std r0,0(r25)
208: e8 1f 00 d8 ld r0,216(r31)
20c: 91 59 00 0c stw r10,12(r25)
210: 7c 1b 02 14 add r0,r27,r0
214: 54 00 04 3e clrlwi r0,r0,16
218: 90 19 00 08 stw r0,8(r25)
21c: 40 9e 00 0c bne- cr7,228 <.skb_to_sgvec+0x108>
220: 3b 00 00 01 li r24,1
224: 48 00 01 a4 b 3c8 <.skb_to_sgvec+0x2a8>
228: 7c 0a da 14 add r0,r10,r27
22c: 3b 00 00 01 li r24,1
230: 7c 1b 07 b4 extsw r27,r0
234: 3a c0 00 00 li r22,0
238: 3a e0 00 10 li r23,16
23c: 48 00 00 ac b 2e8 <.skb_to_sgvec+0x1c8>
240: 40 b8 00 18 bge+ cr6,258 <.skb_to_sgvec+0x138>
244: e8 7e 80 20 ld r3,-32736(r30)
248: e8 9e 80 28 ld r4,-32728(r30)
24c: e8 be 80 30 ld r5,-32720(r30)
250: 48 00 00 01 bl 250 <.skb_to_sgvec+0x130>
254: 60 00 00 00 nop
258: e8 1f 00 e8 ld r0,232(r31)
25c: 7b a9 26 e4 rldicr r9,r29,4,59
260: 7b 0a 2e a4 rldicr r10,r24,5,58
264: 39 18 00 01 addi r8,r24,1
268: 7c b9 52 14 add r5,r25,r10
26c: 7d 29 02 14 add r9,r9,r0
270: 7d 60 ba 14 add r11,r0,r23
274: 3a f7 00 10 addi r23,r23,16
278: a0 09 00 22 lhz r0,34(r9)
27c: 38 cb 00 08 addi r6,r11,8
280: 7c 00 d2 14 add r0,r0,r26
284: 7c 07 07 b4 extsw r7,r0
288: 7c 1b 38 50 subf r0,r27,r7
28c: 7c 00 07 b4 extsw r0,r0
290: 2f 80 00 00 cmpwi cr7,r0,0
294: 7c 09 03 78 mr r9,r0
298: 7f 00 e0 00 cmpw cr6,r0,r28
29c: 40 9d 00 48 ble- cr7,2e4 <.skb_to_sgvec+0x1c4>
2a0: 7d 18 07 b4 extsw r24,r8
2a4: 40 99 00 08 ble- cr6,2ac <.skb_to_sgvec+0x18c>
2a8: 7f 89 e3 78 mr r9,r28
2ac: e8 0b 00 08 ld r0,8(r11)
2b0: 7d 29 07 b4 extsw r9,r9
2b4: 7d 69 e0 50 subf r11,r9,r28
2b8: 7c 19 51 2a stdx r0,r25,r10
2bc: 7d 7c 07 b4 extsw r28,r11
2c0: 7d 69 da 14 add r11,r9,r27
2c4: 2f bc 00 00 cmpdi cr7,r28,0
2c8: a0 06 00 08 lhz r0,8(r6)
2cc: 91 25 00 0c stw r9,12(r5)
2d0: 7c 00 da 14 add r0,r0,r27
2d4: 7d 7b 07 b4 extsw r27,r11
2d8: 7c 1a 00 50 subf r0,r26,r0
2dc: 90 05 00 08 stw r0,8(r5)
2e0: 41 9e 00 e8 beq- cr7,3c8 <.skb_to_sgvec+0x2a8>
2e4: 7c fa 3b 78 mr r26,r7
2e8: e8 7f 00 e8 ld r3,232(r31)
2ec: 7e dd 07 b4 extsw r29,r22
2f0: 7c 1c da 14 add r0,r28,r27
2f4: 3a d6 00 01 addi r22,r22,1
2f8: 38 c0 02 3c li r6,572
2fc: 7f 00 d0 00 cmpw cr6,r0,r26
300: a1 23 00 04 lhz r9,4(r3)
304: 7f 89 e8 00 cmpw cr7,r9,r29
308: 41 9d ff 38 bgt+ cr7,240 <.skb_to_sgvec+0x120>
30c: eb a3 00 10 ld r29,16(r3)
310: 2f bd 00 00 cmpdi cr7,r29,0
314: 41 9e 00 94 beq- cr7,3a8 <.skb_to_sgvec+0x288>
318: 7c 1b e2 14 add r0,r27,r28
31c: 38 c0 02 55 li r6,597
320: 7f 80 d0 00 cmpw cr7,r0,r26
324: 40 bc 00 18 bge+ cr7,33c <.skb_to_sgvec+0x21c>
328: e8 9e 80 28 ld r4,-32728(r30)
32c: e8 be 80 30 ld r5,-32720(r30)
330: e8 7e 80 20 ld r3,-32736(r30)
334: 48 00 00 01 bl 334 <.skb_to_sgvec+0x214>
338: 60 00 00 00 nop
33c: 80 1d 00 88 lwz r0,136(r29)
340: 7d 5a d8 50 subf r10,r26,r27
344: 7b 0b 2e a4 rldicr r11,r24,5,58
348: 7f a3 eb 78 mr r3,r29
34c: 7d 45 07 b4 extsw r5,r10
350: 7c 99 5a 14 add r4,r25,r11
354: 7c 00 d2 14 add r0,r0,r26
358: 7c 00 07 b4 extsw r0,r0
35c: 7d 3b 00 50 subf r9,r27,r0
360: 7c 1a 03 78 mr r26,r0
364: 7d 3f 07 b4 extsw r31,r9
368: 2f 9f 00 00 cmpwi cr7,r31,0
36c: 7f e6 fb 78 mr r6,r31
370: 7f 1f e0 00 cmpw cr6,r31,r28
374: 40 9d 00 2c ble- cr7,3a0 <.skb_to_sgvec+0x280>
378: 41 99 00 38 bgt- cr6,3b0 <.skb_to_sgvec+0x290>
37c: 48 00 00 01 bl 37c <.skb_to_sgvec+0x25c>
380: 7c 1f e0 50 subf r0,r31,r28
384: 7d 3f da 14 add r9,r31,r27
388: 7c 63 c2 14 add r3,r3,r24
38c: 7c 1c 07 b4 extsw r28,r0
390: 7d 3b 07 b4 extsw r27,r9
394: 7c 78 07 b4 extsw r24,r3
398: 2f bc 00 00 cmpdi cr7,r28,0
39c: 41 9e 00 2c beq- cr7,3c8 <.skb_to_sgvec+0x2a8>
3a0: eb bd 00 00 ld r29,0(r29)
3a4: 4b ff ff 6c b 310 <.skb_to_sgvec+0x1f0>
3a8: 0b 1c 00 00 tdnei r28,0
3ac: 48 00 00 1c b 3c8 <.skb_to_sgvec+0x2a8>
3b0: 7c 15 c2 14 add r0,r21,r24
3b4: 7f 39 5a 14 add r25,r25,r11
3b8: 7d 5b 07 b4 extsw r27,r10
3bc: 7f bf eb 78 mr r31,r29
3c0: 7c 15 07 b4 extsw r21,r0
3c4: 4b ff fd ac b 170 <.skb_to_sgvec+0x50>
3c8: 38 21 00 d0 addi r1,r1,208
3cc: 7c 75 c2 14 add r3,r21,r24
3d0: e8 01 00 10 ld r0,16(r1)
3d4: 7c 63 07 b4 extsw r3,r3
3d8: ea a1 ff a8 ld r21,-88(r1)
3dc: ea c1 ff b0 ld r22,-80(r1)
3e0: ea e1 ff b8 ld r23,-72(r1)
3e4: eb 01 ff c0 ld r24,-64(r1)
3e8: eb 21 ff c8 ld r25,-56(r1)
3ec: eb 41 ff d0 ld r26,-48(r1)
3f0: eb 61 ff d8 ld r27,-40(r1)
3f4: 7c 08 03 a6 mtlr r0
3f8: eb 81 ff e0 ld r28,-32(r1)
3fc: eb a1 ff e8 ld r29,-24(r1)
400: eb c1 ff f0 ld r30,-16(r1)
404: eb e1 ff f8 ld r31,-8(r1)
408: 4e 80 00 20 blr
^ permalink raw reply
* Re: Driver for OCP Driver for PPC405
From: Matt Porter @ 2006-08-30 17:25 UTC (permalink / raw)
To: akhilesh; +Cc: linuxppc-embedded
In-Reply-To: <1417.59.165.59.34.1156954325.squirrel@59.165.59.34>
On Wed, Aug 30, 2006 at 09:42:05PM +0530, akhilesh@innomedia.soft.net wrote:
> Hi,
>
> I need a OCP IDE driver for IBM PPC405 redwood6 platform for 2.6 kernel.
> Any pointer for same or similar driver would be highly appreciated.
List archives are your friend.
http://ozlabs.org/pipermail/linuxppc-embedded/2005-February/016715.html
Read the whole thread...there's a patch that applies to linuxppc-2.5 (and
the location to rsync that old tree) in a later mail. It didn't go
upstream because the author didn't clean up some minor things needed
for upstream inclusion.
-Matt
^ permalink raw reply
* Re: [PATCH] EHCI Oops on CONFIG_NOT_COHERENT_CACHE system
From: Marcus Comstedt @ 2006-08-30 17:42 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <3e3f83654b861ae77c6c07cf207ba6af@bga.com>
Milton Miller <miltonm@bga.com> writes:
> I think its a case of the people that know the architecture agree
> that atomics and DMA do not mix, and that this is an issue for
> usb-devel to fix.
That was precisely the kind of agreement I was looking for. :-)
> The other question is: does the current access polute the cache by
> reading things where the device is supposed to be writing?
Well, that shouldn't be an issue as the page is cache-inhibited.
And on systems with cache coherency, where the pages are not cache-
inhibited, this would be handled by bus snooping, right?
> My suggestion is take the issue over there, and only cc us here if
> you get pushback over there.
Ok, will do. Thanks.
// Marcus
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Adam Litke @ 2006-08-30 17:44 UTC (permalink / raw)
To: Andi Kleen
Cc: linux-mm, Nishanth Aravamudan, lnxninja, linuxppc-dev,
Christoph Lameter
In-Reply-To: <200608300919.13125.ak@suse.de>
On Wed, 2006-08-30 at 09:19 +0200, Andi Kleen wrote:
> mous pages.
> >
> > The order is (with necessary params filled in):
> >
> > p = mmap( , newsize, RW, PRIVATE, unlinked_hugetlbfs_heap_fd, );
> >
> > numa_interleave_memory(p, newsize);
> >
> > mlock(p, newsize); /* causes all the hugepages to be faulted in */
> >
> > munlock(p,newsize);
> >
> > From what I gathered from the numa manpages, the interleave policy
> > should take effect on the mlock, as that is "fault-time" in this
> > context. We're forcing the fault, that is.
>
> mlock shouldn't be needed at all here. the new hugetlbfs is supposed
> to reserve at mmap time and numa_interleave_memory() sets a VMA
> policy which will should do the right thing no matter when the fault
> occurs.
mmap-time reservation of huge pages is done only for shared mappings.
MAP_PRIVATE mappings have full-overcommit semantics. We use the mlock
call to "guarantee" the MAP_PRIVATE memory to the process. If mlock
fails, we simply unmap the hugetlb region and tell glibc to revert to
its normal allocation method (mmap normal pages).
> Hmm, maybe mlock() policy() is broken.
The policy decision is made further down than mlock. As each huge page
is allocated from the static pool, the policy is consulted to see from
which node to pop a huge page.
The function huge_zonelist() seems to encapsulate the numa policy logic
and after sniffing the code, it looks right to me.
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Tim Pepper @ 2006-08-30 18:01 UTC (permalink / raw)
To: Andi Kleen; +Cc: linux-mm, Nishanth Aravamudan, linuxppc-dev, Christoph Lameter
In-Reply-To: <200608300932.23746.ak@suse.de>
On 8/30/06, Andi Kleen <ak@suse.de> wrote:
> Then it's probably some new problem in hugetlbfs.
It's something subtle though, because I _am_ able to get interleaving
on hugetlbfs with a slightly simplified test case (see previous email)
compared to Nish's.
> Does it work with shmfs?
Haven't tried shmfs, but the following correctly does the expected
interleaving with hugepages (although not hugetlbfs backed):
shmid = shmget( 0, NR_HUGE_PAGES, IPC_CREAT | SHM_HUGETLB | 0666 );
shmat_addr = shmat( shmid, NULL, 0 );
...
numa_interleave_memory( shmat_addr, SHM_SIZE, &nm );
I'd expect it works fine with non-huge pages, shmfs.
> The regression test for hugetlbfs is numactl is unfortunately still disabled.
> I need to enable it at some point for hugetlbfs now that it reached mainline.
On my list of random things to do is trying to improve the test
coverage in this area. We keep running into bugs or possible bugs or
confusion on expected behaviour. I'm going through the code trying to
understand it and writing little programs to confirm my understanding
here and there anyway.
Tim
^ permalink raw reply
* Re: [PATCH] powerpc: emulate power5 popcntb instruction
From: Will Schmidt @ 2006-08-30 18:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras, segher, arnd
In-Reply-To: <6DCD2C4D-BB97-487D-A094-7F288970F3F3@kernel.crashing.org>
On Tue, 2006-29-08 at 08:43 +0200, Segher Boessenkool wrote:
> >> I just did a patch to fix the existing masks.
>
> Thanks Paul.
>
> >> Could you do a new
> >> version of this patch that doesn't include the unrelated mask fixes
> >> please? Also it would be really nice if you could figure out a
> >> way to
> >> avoid doing the unnecessary 64-bit logical operations on 32-bit
> >> machines - i.e. using an unsigned long for tmp, but then the
> >> constants
> >> become problematic. Maybe you need something like
> >>
> >> #define LCONST(x) ((unsigned long)(x##ULL))
> >
> > Ok, how about this..
>
> Hrm. The LCONST() thing is butt ugly though; you can just write
> 0x3333333333333333ULL etc. and GCC will do the right thing (i.e.
> efficient code), and not warn (don't need the "ULL" even when in
> C99/gnu99 mode, as we should be but aren't, heh).
>
> You want to make tmp and unsigned long instead of an u64...
Ok, so back to unsigned-long to let the 32-bit stuff be happy..
Now a bit of a tangent question: As far as just 64-bit is concerned, is
there actually any difference between u64 and unsigned long? Am
wondering why you suggested that change to u64 from unsigned long
earlier in the thread.
this version looks to build clean with arch=ppc (32-bit).
This provides emulation of the power5 instruction popcntb.
Signed-off-by: Will Schmidt <will_schmidt@vnet.ibm.com>
---
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 2105767..4014d71 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -588,6 +588,9 @@ #define INST_LSWX 0x7c00042a
#define INST_STSWI 0x7c0005aa
#define INST_STSWX 0x7c00052a
+#define INST_POPCNTB 0x7c0000f4
+#define INST_POPCNTB_MASK 0xfc0007fe
+
static int emulate_string_inst(struct pt_regs *regs, u32 instword)
{
u8 rT = (instword >> 21) & 0x1f;
@@ -656,6 +659,23 @@ static int emulate_string_inst(struct pt
return 0;
}
+static int emulate_popcntb_inst(struct pt_regs *regs, u32 instword)
+{
+ u32 ra,rs;
+ unsigned long tmp;
+
+ ra = (instword >> 16) & 0x1f;
+ rs = (instword >> 21) & 0x1f;
+
+ tmp = regs->gpr[rs];
+ tmp = tmp - ((tmp >> 1) & 0x5555555555555555ULL);
+ tmp = (tmp & 0x3333333333333333ULL) + ((tmp >> 2) & 0x3333333333333333ULL);
+ tmp = (tmp + (tmp >> 4)) & 0x0f0f0f0f0f0f0f0fULL;
+ regs->gpr[ra] = tmp;
+
+ return 0;
+}
+
static int emulate_instruction(struct pt_regs *regs)
{
u32 instword;
@@ -693,6 +713,11 @@ static int emulate_instruction(struct pt
if ((instword & INST_STRING_GEN_MASK) == INST_STRING)
return emulate_string_inst(regs, instword);
+ /* Emulate the popcntb (Population Count Bytes) instruction. */
+ if ((instword & INST_POPCNTB_MASK) == INST_POPCNTB) {
+ return emulate_popcntb_inst(regs, instword);
+ }
+
return -EINVAL;
}
^ permalink raw reply related
* Re: libnuma interleaving oddness
From: Adam Litke @ 2006-08-30 18:13 UTC (permalink / raw)
To: Tim Pepper
Cc: linux-mm, Nishanth Aravamudan, Andi Kleen, linuxppc-dev,
Christoph Lameter
In-Reply-To: <eada2a070608301101j205b2711va5c287dbf8aab492@mail.gmail.com>
On Wed, 2006-08-30 at 11:01 -0700, Tim Pepper wrote:
> On 8/30/06, Andi Kleen <ak@suse.de> wrote:
> > Then it's probably some new problem in hugetlbfs.
>
> It's something subtle though, because I _am_ able to get interleaving
> on hugetlbfs with a slightly simplified test case (see previous email)
> compared to Nish's.
>
> > Does it work with shmfs?
>
> Haven't tried shmfs, but the following correctly does the expected
> interleaving with hugepages (although not hugetlbfs backed):
> shmid = shmget( 0, NR_HUGE_PAGES, IPC_CREAT | SHM_HUGETLB | 0666 );
> shmat_addr = shmat( shmid, NULL, 0 );
> ...
> numa_interleave_memory( shmat_addr, SHM_SIZE, &nm );
> I'd expect it works fine with non-huge pages, shmfs.
Actually, the above call will yield hugetlbfs backed huge pages. The
kernel just prepares the hugetlbfs file for you. See
hugetlb_zero_setup().
--
Adam Litke - (agl at us.ibm.com)
IBM Linux Technology Center
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Andi Kleen @ 2006-08-30 18:12 UTC (permalink / raw)
To: Tim Pepper; +Cc: linux-mm, Nishanth Aravamudan, linuxppc-dev, Christoph Lameter
In-Reply-To: <eada2a070608301101j205b2711va5c287dbf8aab492@mail.gmail.com>
> On my list of random things to do is trying to improve the test
> coverage in this area. We keep running into bugs or possible bugs or
> confusion on expected behaviour. I'm going through the code trying to
> understand it and writing little programs to confirm my understanding
> here and there anyway.
numactl has a little regression test suite in test/* that tests a lot of stuff,
but not all. Feel free to extend it.
-Andi
^ permalink raw reply
* Re: [openib-general] [PATCH 02/13] IB/ehca: includes
From: Hoang-Nam Nguyen @ 2006-08-30 18:27 UTC (permalink / raw)
To: abergman
Cc: linux-kernel, openib-general, linuxppc-dev, Christoph Raisch,
Marcus Eder, openib-general-bounces, abergman
In-Reply-To: <200608301143.35320.arnd.bergmann@de.ibm.com>
Hi,
> There are a few places in the driver where you declare
> external variables (mostly ehca_module and ehca_debug_level)
> from C files instead of a header. This sometimes leads
> to bugs when a type changes and is therefore considered
> bad style.
Good point. See patch attached below.
> Moreover, for some of your more heavily used caches, you may
> want to look into using constructor/destructor calls to
> speed up allocation.
That makes sense. Will look into this for a later patch.
Thanks!
Nam
Makefile | 1
ehca_av.c | 29 +++++++---
ehca_classes.h | 27 +++++----
ehca_cq.c | 27 +++++++--
ehca_eq.c | 14 ----
ehca_irq.c | 1
ehca_main.c | 164
++++++++++++++++++++-------------------------------------
ehca_mrmw.c | 45 +++++++++++----
ehca_pd.c | 25 +++++++-
ehca_qp.c | 32 +++++++----
ehca_reqs.c | 2
ehca_sqp.c | 2
hcp_if.c | 1
hcp_phyp.h | 4 -
ipz_pt_fn.c | 2
15 files changed, 198 insertions(+), 178 deletions(-)
diff -Nurp infiniband/drivers/infiniband/hw/ehca/Makefile
infiniband_work/drivers/infiniband/hw/ehca/Makefile
--- infiniband/drivers/infiniband/hw/ehca/Makefile 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/Makefile 2006-08-30
20:00:17.000000000 +0200
@@ -10,6 +10,7 @@
obj-$(CONFIG_INFINIBAND_EHCA) += ib_ehca.o
+
ib_ehca-objs = ehca_main.o ehca_hca.o ehca_mcast.o ehca_pd.o ehca_av.o
ehca_eq.o \
ehca_cq.o ehca_qp.o ehca_sqp.o ehca_mrmw.o ehca_reqs.o
ehca_irq.o \
ehca_uverbs.o ipz_pt_fn.o hcp_if.o hcp_phyp.o
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_av.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_av.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_av.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_av.c 2006-08-30
20:00:16.000000000 +0200
@@ -48,16 +48,16 @@
#include "ehca_iverbs.h"
#include "hcp_if.h"
+static struct kmem_cache *av_cache;
+
struct ib_ah *ehca_create_ah(struct ib_pd *pd, struct ib_ah_attr *ah_attr)
{
- extern struct ehca_module ehca_module;
- extern int ehca_static_rate;
int ret;
struct ehca_av *av;
struct ehca_shca *shca = container_of(pd->device, struct ehca_shca,
ib_device);
- av = kmem_cache_alloc(ehca_module.cache_av, SLAB_KERNEL);
+ av = kmem_cache_alloc(av_cache, SLAB_KERNEL);
if (!av) {
ehca_err(pd->device, "Out of memory pd=%p ah_attr=%p",
pd, ah_attr);
@@ -128,7 +128,7 @@ struct ib_ah *ehca_create_ah(struct ib_p
return &av->ib_ah;
create_ah_exit1:
- kmem_cache_free(ehca_module.cache_av, av);
+ kmem_cache_free(av_cache, av);
return ERR_PTR(ret);
}
@@ -238,7 +238,6 @@ int ehca_query_ah(struct ib_ah *ah, stru
int ehca_destroy_ah(struct ib_ah *ah)
{
- extern struct ehca_module ehca_module;
struct ehca_pd *my_pd = container_of(ah->pd, struct ehca_pd, ib_pd);
u32 cur_pid = current->tgid;
@@ -249,8 +248,24 @@ int ehca_destroy_ah(struct ib_ah *ah)
return -EINVAL;
}
- kmem_cache_free(ehca_module.cache_av,
- container_of(ah, struct ehca_av, ib_ah));
+ kmem_cache_free(av_cache, container_of(ah, struct ehca_av, ib_ah));
+
+ return 0;
+}
+int ehca_init_av_cache(void)
+{
+ av_cache = kmem_cache_create("ehca_cache_av",
+ sizeof(struct ehca_av), 0,
+ SLAB_HWCACHE_ALIGN,
+ NULL, NULL);
+ if (!av_cache)
+ return -ENOMEM;
return 0;
}
+
+void ehca_cleanup_av_cache(void)
+{
+ if (av_cache)
+ kmem_cache_destroy(av_cache);
+}
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_classes.h
infiniband_work/drivers/infiniband/hw/ehca/ehca_classes.h
--- infiniband/drivers/infiniband/hw/ehca/ehca_classes.h 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_classes.h
2006-08-30 20:00:16.000000000 +0200
@@ -63,18 +63,6 @@ struct ehca_av;
#include "ehca_irq.h"
-struct ehca_module {
- struct list_head shca_list;
- spinlock_t shca_lock;
- struct timer_list timer;
- kmem_cache_t *cache_pd;
- kmem_cache_t *cache_cq;
- kmem_cache_t *cache_qp;
- kmem_cache_t *cache_av;
- kmem_cache_t *cache_mr;
- kmem_cache_t *cache_mw;
-};
-
struct ehca_eq {
u32 length;
struct ipz_queue ipz_queue;
@@ -274,11 +262,26 @@ int ehca_shca_delete(struct ehca_shca *m
struct ehca_sport *ehca_sport_new(struct ehca_shca *anchor);
+int ehca_init_pd_cache(void);
+void ehca_cleanup_pd_cache(void);
+int ehca_init_cq_cache(void);
+void ehca_cleanup_cq_cache(void);
+int ehca_init_qp_cache(void);
+void ehca_cleanup_qp_cache(void);
+int ehca_init_av_cache(void);
+void ehca_cleanup_av_cache(void);
+int ehca_init_mrmw_cache(void);
+void ehca_cleanup_mrmw_cache(void);
+
extern spinlock_t ehca_qp_idr_lock;
extern spinlock_t ehca_cq_idr_lock;
extern struct idr ehca_qp_idr;
extern struct idr ehca_cq_idr;
+extern int ehca_static_rate;
+extern int ehca_port_act_time;
+extern int ehca_use_hp_mr;
+
struct ipzu_queue_resp {
u64 queue; /* points to first queue entry */
u32 qe_size; /* queue entry size */
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_cq.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_cq.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_cq.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_cq.c 2006-08-30
20:00:17.000000000 +0200
@@ -50,6 +50,8 @@
#include "ehca_irq.h"
#include "hcp_if.h"
+static struct kmem_cache *cq_cache;
+
int ehca_cq_assign_qp(struct ehca_cq *cq, struct ehca_qp *qp)
{
unsigned int qp_num = qp->real_qp_num;
@@ -115,7 +117,6 @@ struct ib_cq *ehca_create_cq(struct ib_d
struct ib_ucontext *context,
struct ib_udata *udata)
{
- extern struct ehca_module ehca_module;
static const u32 additional_cqe = 20;
struct ib_cq *cq;
struct ehca_cq *my_cq;
@@ -133,7 +134,7 @@ struct ib_cq *ehca_create_cq(struct ib_d
if (cqe >= 0xFFFFFFFF - 64 - additional_cqe)
return ERR_PTR(-EINVAL);
- my_cq = kmem_cache_alloc(ehca_module.cache_cq, SLAB_KERNEL);
+ my_cq = kmem_cache_alloc(cq_cache, SLAB_KERNEL);
if (!my_cq) {
ehca_err(device, "Out of memory for ehca_cq struct device=%p",
device);
@@ -324,14 +325,13 @@ create_cq_exit2:
spin_unlock_irqrestore(&ehca_cq_idr_lock, flags);
create_cq_exit1:
- kmem_cache_free(ehca_module.cache_cq, my_cq);
+ kmem_cache_free(cq_cache, my_cq);
return cq;
}
int ehca_destroy_cq(struct ib_cq *cq)
{
- extern struct ehca_module ehca_module;
u64 h_ret;
int ret;
struct ehca_cq *my_cq = container_of(cq, struct ehca_cq, ib_cq);
@@ -387,7 +387,7 @@ int ehca_destroy_cq(struct ib_cq *cq)
return ehca2ib_return_code(h_ret);
}
ipz_queue_dtor(&my_cq->ipz_queue);
- kmem_cache_free(ehca_module.cache_cq, my_cq);
+ kmem_cache_free(cq_cache, my_cq);
return 0;
}
@@ -408,3 +408,20 @@ int ehca_resize_cq(struct ib_cq *cq, int
return -EFAULT;
}
+
+int ehca_init_cq_cache(void)
+{
+ cq_cache = kmem_cache_create("ehca_cache_cq",
+ sizeof(struct ehca_cq), 0,
+ SLAB_HWCACHE_ALIGN,
+ NULL, NULL);
+ if (!cq_cache)
+ return -ENOMEM;
+ return 0;
+}
+
+void ehca_cleanup_cq_cache(void)
+{
+ if (cq_cache)
+ kmem_cache_destroy(cq_cache);
+}
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_eq.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_eq.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_eq.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_eq.c 2006-08-30
20:00:16.000000000 +0200
@@ -163,20 +163,6 @@ void *ehca_poll_eq(struct ehca_shca *shc
return eqe;
}
-void ehca_poll_eqs(unsigned long data)
-{
- struct ehca_shca *shca;
- struct ehca_module *module = (struct ehca_module*)data;
-
- spin_lock(&module->shca_lock);
- list_for_each_entry(shca, &module->shca_list, shca_list) {
- if (shca->eq.is_initialized)
- ehca_tasklet_eq((unsigned long)(void*)shca);
- }
- mod_timer(&module->timer, jiffies + HZ);
- spin_unlock(&module->shca_lock);
-}
-
int ehca_destroy_eq(struct ehca_shca *shca, struct ehca_eq *eq)
{
unsigned long flags;
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_irq.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_irq.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_irq.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_irq.c 2006-08-30
20:00:16.000000000 +0200
@@ -427,7 +427,6 @@ void ehca_tasklet_eq(unsigned long data)
/* TODO: better structure */
if (EHCA_BMASK_GET(EQE_COMPLETION_EVENT,
eqe_value)) {
- extern struct idr ehca_cq_idr;
unsigned long flags;
u32 token;
struct ehca_cq *cq;
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_main.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_main.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_main.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_main.c 2006-08-30
20:01:34.000000000 +0200
@@ -4,6 +4,7 @@
* module start stop, hca detection
*
* Authors: Heiko J Schick <schickhj@de.ibm.com>
+ * Hoang-Nam Nguyen <hnguyen@de.ibm.com>
*
* Copyright (c) 2005 IBM Corporation
*
@@ -47,7 +48,7 @@
MODULE_LICENSE("Dual BSD/GPL");
MODULE_AUTHOR("Christoph Raisch <raisch@de.ibm.com>");
MODULE_DESCRIPTION("IBM eServer HCA InfiniBand Device Driver");
-MODULE_VERSION("SVNEHCA_0014");
+MODULE_VERSION("SVNEHCA_0015");
int ehca_open_aqp1 = 0;
int ehca_debug_level = 0;
@@ -92,129 +93,69 @@ spinlock_t ehca_cq_idr_lock;
DEFINE_IDR(ehca_qp_idr);
DEFINE_IDR(ehca_cq_idr);
-struct ehca_module ehca_module;
+static struct list_head shca_list; /* list of all registered ehcas */
+static spinlock_t shca_list_lock;
-int ehca_create_slab_caches(struct ehca_module *ehca_module)
+static struct timer_list poll_eqs_timer;
+
+static int ehca_create_slab_caches(void)
{
int ret;
- ehca_module->cache_pd =
- kmem_cache_create("ehca_cache_pd",
- sizeof(struct ehca_pd),
- 0, SLAB_HWCACHE_ALIGN,
- NULL, NULL);
- if (!ehca_module->cache_pd) {
+ ret = ehca_init_pd_cache();
+ if (ret) {
ehca_gen_err("Cannot create PD SLAB cache.");
- ret = -ENOMEM;
- goto create_slab_caches1;
+ return ret;
}
- ehca_module->cache_cq =
- kmem_cache_create("ehca_cache_cq",
- sizeof(struct ehca_cq),
- 0, SLAB_HWCACHE_ALIGN,
- NULL, NULL);
- if (!ehca_module->cache_cq) {
+ ret = ehca_init_cq_cache();
+ if (ret) {
ehca_gen_err("Cannot create CQ SLAB cache.");
- ret = -ENOMEM;
goto create_slab_caches2;
}
- ehca_module->cache_qp =
- kmem_cache_create("ehca_cache_qp",
- sizeof(struct ehca_qp),
- 0, SLAB_HWCACHE_ALIGN,
- NULL, NULL);
- if (!ehca_module->cache_qp) {
+ ret = ehca_init_qp_cache();
+ if (ret) {
ehca_gen_err("Cannot create QP SLAB cache.");
- ret = -ENOMEM;
goto create_slab_caches3;
}
- ehca_module->cache_av =
- kmem_cache_create("ehca_cache_av",
- sizeof(struct ehca_av),
- 0, SLAB_HWCACHE_ALIGN,
- NULL, NULL);
- if (!ehca_module->cache_av) {
+ ret = ehca_init_av_cache();
+ if (ret) {
ehca_gen_err("Cannot create AV SLAB cache.");
- ret = -ENOMEM;
goto create_slab_caches4;
}
- ehca_module->cache_mw =
- kmem_cache_create("ehca_cache_mw",
- sizeof(struct ehca_mw),
- 0, SLAB_HWCACHE_ALIGN,
- NULL, NULL);
- if (!ehca_module->cache_mw) {
- ehca_gen_err("Cannot create MW SLAB cache.");
- ret = -ENOMEM;
+ ret = ehca_init_mrmw_cache();
+ if (ret) {
+ ehca_gen_err("Cannot create MR&MW SLAB cache.");
goto create_slab_caches5;
}
- ehca_module->cache_mr =
- kmem_cache_create("ehca_cache_mr",
- sizeof(struct ehca_mr),
- 0, SLAB_HWCACHE_ALIGN,
- NULL, NULL);
- if (!ehca_module->cache_mr) {
- ehca_gen_err("Cannot create MR SLAB cache.");
- ret = -ENOMEM;
- goto create_slab_caches6;
- }
-
return 0;
-create_slab_caches6:
- kmem_cache_destroy(ehca_module->cache_mw);
-
create_slab_caches5:
- kmem_cache_destroy(ehca_module->cache_av);
+ ehca_cleanup_av_cache();
create_slab_caches4:
- kmem_cache_destroy(ehca_module->cache_qp);
+ ehca_cleanup_qp_cache();
create_slab_caches3:
- kmem_cache_destroy(ehca_module->cache_cq);
+ ehca_cleanup_cq_cache();
create_slab_caches2:
- kmem_cache_destroy(ehca_module->cache_pd);
-
-create_slab_caches1:
+ ehca_cleanup_pd_cache();
return ret;
}
-int ehca_destroy_slab_caches(struct ehca_module *ehca_module)
+static void ehca_destroy_slab_caches(void)
{
- int ret;
-
- ret = kmem_cache_destroy(ehca_module->cache_pd);
- if (ret)
- ehca_gen_err("Cannot destroy PD SLAB cache. ret=%x", ret);
-
- ret = kmem_cache_destroy(ehca_module->cache_cq);
- if (ret)
- ehca_gen_err("Cannot destroy CQ SLAB cache. ret=%x", ret);
-
- ret = kmem_cache_destroy(ehca_module->cache_qp);
- if (ret)
- ehca_gen_err("Cannot destroy QP SLAB cache. ret=%x", ret);
-
- ret = kmem_cache_destroy(ehca_module->cache_av);
- if (ret)
- ehca_gen_err("Cannot destroy AV SLAB cache. ret=%x", ret);
-
- ret = kmem_cache_destroy(ehca_module->cache_mw);
- if (ret)
- ehca_gen_err("Cannot destroy MW SLAB cache. ret=%x", ret);
-
- ret = kmem_cache_destroy(ehca_module->cache_mr);
- if (ret)
- ehca_gen_err("Cannot destroy MR SLAB cache. ret=%x", ret);
-
- return 0;
+ ehca_cleanup_mrmw_cache();
+ ehca_cleanup_av_cache();
+ ehca_cleanup_qp_cache();
+ ehca_cleanup_cq_cache();
+ ehca_cleanup_pd_cache();
}
#define EHCA_HCAAVER EHCA_BMASK_IBM(32,39)
@@ -682,9 +623,9 @@ static int __devinit ehca_probe(struct i
ehca_create_device_sysfs(dev);
- spin_lock(&ehca_module.shca_lock);
- list_add(&shca->shca_list, &ehca_module.shca_list);
- spin_unlock(&ehca_module.shca_lock);
+ spin_lock(&shca_list_lock);
+ list_add(&shca->shca_list, &shca_list);
+ spin_unlock(&shca_list_lock);
return 0;
@@ -767,9 +708,9 @@ static int __devexit ehca_remove(struct
ib_dealloc_device(&shca->ib_device);
- spin_lock(&ehca_module.shca_lock);
+ spin_lock(&shca_list_lock);
list_del(&shca->shca_list);
- spin_unlock(&ehca_module.shca_lock);
+ spin_unlock(&shca_list_lock);
return ret;
}
@@ -790,26 +731,39 @@ static struct ibmebus_driver ehca_driver
.remove = ehca_remove,
};
+void ehca_poll_eqs(unsigned long data)
+{
+ struct ehca_shca *shca;
+
+ spin_lock(&shca_list_lock);
+ list_for_each_entry(shca, &shca_list, shca_list) {
+ if (shca->eq.is_initialized)
+ ehca_tasklet_eq((unsigned long)(void*)shca);
+ }
+ mod_timer(&poll_eqs_timer, jiffies + HZ);
+ spin_unlock(&shca_list_lock);
+}
+
int __init ehca_module_init(void)
{
int ret;
printk(KERN_INFO "eHCA Infiniband Device Driver "
- "(Rel.: SVNEHCA_0014)\n");
+ "(Rel.: SVNEHCA_0015)\n");
idr_init(&ehca_qp_idr);
idr_init(&ehca_cq_idr);
spin_lock_init(&ehca_qp_idr_lock);
spin_lock_init(&ehca_cq_idr_lock);
- INIT_LIST_HEAD(&ehca_module.shca_list);
- spin_lock_init(&ehca_module.shca_lock);
+ INIT_LIST_HEAD(&shca_list);
+ spin_lock_init(&shca_list_lock);
if ((ret = ehca_create_comp_pool())) {
ehca_gen_err("Cannot create comp pool.");
return ret;
}
- if ((ret = ehca_create_slab_caches(&ehca_module))) {
+ if ((ret = ehca_create_slab_caches())) {
ehca_gen_err("Cannot create SLAB caches");
ret = -ENOMEM;
goto module_init1;
@@ -827,17 +781,16 @@ int __init ehca_module_init(void)
ehca_gen_err("WARNING!!!");
ehca_gen_err("It is possible to lose interrupts.");
} else {
- init_timer(&ehca_module.timer);
- ehca_module.timer.function = ehca_poll_eqs;
- ehca_module.timer.data = (unsigned long)&ehca_module;
- ehca_module.timer.expires = jiffies + HZ;
- add_timer(&ehca_module.timer);
+ init_timer(&poll_eqs_timer);
+ poll_eqs_timer.function = ehca_poll_eqs;
+ poll_eqs_timer.expires = jiffies + HZ;
+ add_timer(&poll_eqs_timer);
}
return 0;
module_init2:
- ehca_destroy_slab_caches(&ehca_module);
+ ehca_destroy_slab_caches();
module_init1:
ehca_destroy_comp_pool();
@@ -847,13 +800,12 @@ module_init1:
void __exit ehca_module_exit(void)
{
if (ehca_poll_all_eqs == 1)
- del_timer_sync(&ehca_module.timer);
+ del_timer_sync(&poll_eqs_timer);
ehca_remove_driver_sysfs(&ehca_driver);
ibmebus_unregister_driver(&ehca_driver);
- if (ehca_destroy_slab_caches(&ehca_module) != 0)
- ehca_gen_err("Cannot destroy SLAB caches");
+ ehca_destroy_slab_caches();
ehca_destroy_comp_pool();
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_mrmw.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_mrmw.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_mrmw.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_mrmw.c 2006-08-30
20:00:16.000000000 +0200
@@ -46,14 +46,14 @@
#include "hcp_if.h"
#include "hipz_hw.h"
-extern int ehca_use_hp_mr;
+static struct kmem_cache *mr_cache;
+static struct kmem_cache *mw_cache;
static struct ehca_mr *ehca_mr_new(void)
{
- extern struct ehca_module ehca_module;
struct ehca_mr *me;
- me = kmem_cache_alloc(ehca_module.cache_mr, SLAB_KERNEL);
+ me = kmem_cache_alloc(mr_cache, SLAB_KERNEL);
if (me) {
memset(me, 0, sizeof(struct ehca_mr));
spin_lock_init(&me->mrlock);
@@ -65,17 +65,14 @@ static struct ehca_mr *ehca_mr_new(void)
static void ehca_mr_delete(struct ehca_mr *me)
{
- extern struct ehca_module ehca_module;
-
- kmem_cache_free(ehca_module.cache_mr, me);
+ kmem_cache_free(mr_cache, me);
}
static struct ehca_mw *ehca_mw_new(void)
{
- extern struct ehca_module ehca_module;
struct ehca_mw *me;
- me = kmem_cache_alloc(ehca_module.cache_mw, SLAB_KERNEL);
+ me = kmem_cache_alloc(mw_cache, SLAB_KERNEL);
if (me) {
memset(me, 0, sizeof(struct ehca_mw));
spin_lock_init(&me->mwlock);
@@ -87,9 +84,7 @@ static struct ehca_mw *ehca_mw_new(void)
static void ehca_mw_delete(struct ehca_mw *me)
{
- extern struct ehca_module ehca_module;
-
- kmem_cache_free(ehca_module.cache_mw, me);
+ kmem_cache_free(mw_cache, me);
}
/*----------------------------------------------------------------------*/
@@ -2236,3 +2231,31 @@ void ehca_mr_deletenew(struct ehca_mr *m
mr->nr_of_pages = 0;
mr->pagearray = NULL;
} /* end ehca_mr_deletenew() */
+
+int ehca_init_mrmw_cache(void)
+{
+ mr_cache = kmem_cache_create("ehca_cache_mr",
+ sizeof(struct ehca_mr), 0,
+ SLAB_HWCACHE_ALIGN,
+ NULL, NULL);
+ if (!mr_cache)
+ return -ENOMEM;
+ mw_cache = kmem_cache_create("ehca_cache_mw",
+ sizeof(struct ehca_mw), 0,
+ SLAB_HWCACHE_ALIGN,
+ NULL, NULL);
+ if (!mw_cache) {
+ kmem_cache_destroy(mr_cache);
+ mr_cache = NULL;
+ return -ENOMEM;
+ }
+ return 0;
+}
+
+void ehca_cleanup_mrmw_cache(void)
+{
+ if (mr_cache)
+ kmem_cache_destroy(mr_cache);
+ if (mw_cache)
+ kmem_cache_destroy(mw_cache);
+}
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_pd.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_pd.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_pd.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_pd.c 2006-08-30
20:00:16.000000000 +0200
@@ -43,13 +43,14 @@
#include "ehca_tools.h"
#include "ehca_iverbs.h"
+static struct kmem_cache *pd_cache;
+
struct ib_pd *ehca_alloc_pd(struct ib_device *device,
struct ib_ucontext *context, struct ib_udata *udata)
{
- extern struct ehca_module ehca_module;
struct ehca_pd *pd;
- pd = kmem_cache_alloc(ehca_module.cache_pd, SLAB_KERNEL);
+ pd = kmem_cache_alloc(pd_cache, SLAB_KERNEL);
if (!pd) {
ehca_err(device, "device=%p context=%p out of memory",
device, context);
@@ -79,7 +80,6 @@ struct ib_pd *ehca_alloc_pd(struct ib_de
int ehca_dealloc_pd(struct ib_pd *pd)
{
- extern struct ehca_module ehca_module;
u32 cur_pid = current->tgid;
struct ehca_pd *my_pd = container_of(pd, struct ehca_pd, ib_pd);
@@ -90,8 +90,25 @@ int ehca_dealloc_pd(struct ib_pd *pd)
return -EINVAL;
}
- kmem_cache_free(ehca_module.cache_pd,
+ kmem_cache_free(pd_cache,
container_of(pd, struct ehca_pd, ib_pd));
return 0;
}
+
+int ehca_init_pd_cache(void)
+{
+ pd_cache = kmem_cache_create("ehca_cache_pd",
+ sizeof(struct ehca_pd), 0,
+ SLAB_HWCACHE_ALIGN,
+ NULL, NULL);
+ if (!pd_cache)
+ return -ENOMEM;
+ return 0;
+}
+
+void ehca_cleanup_pd_cache(void)
+{
+ if (pd_cache)
+ kmem_cache_destroy(pd_cache);
+}
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_qp.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_qp.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_qp.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_qp.c 2006-08-30
20:00:16.000000000 +0200
@@ -51,6 +51,8 @@
#include "hcp_if.h"
#include "hipz_fns.h"
+static struct kmem_cache *qp_cache;
+
/*
* attributes not supported by query qp
*/
@@ -387,7 +389,6 @@ struct ib_qp *ehca_create_qp(struct ib_p
struct ib_qp_init_attr *init_attr,
struct ib_udata *udata)
{
- extern struct ehca_module ehca_module;
static int da_rc_msg_size[]={ 128, 256, 512, 1024, 2048, 4096 };
static int da_ud_sq_msg_size[]={ 128, 384, 896, 1920, 3968 };
struct ehca_qp *my_qp;
@@ -449,7 +450,7 @@ struct ib_qp *ehca_create_qp(struct ib_p
if (pd->uobject && udata)
context = pd->uobject->context;
- my_qp = kmem_cache_alloc(ehca_module.cache_qp, SLAB_KERNEL);
+ my_qp = kmem_cache_alloc(qp_cache, SLAB_KERNEL);
if (!my_qp) {
ehca_err(pd->device, "pd=%p not enough memory to alloc qp",
pd);
return ERR_PTR(-ENOMEM);
@@ -716,7 +717,7 @@ create_qp_exit1:
spin_unlock_irqrestore(&ehca_qp_idr_lock, flags);
create_qp_exit0:
- kmem_cache_free(ehca_module.cache_qp, my_qp);
+ kmem_cache_free(qp_cache, my_qp);
return ERR_PTR(ret);
}
@@ -728,7 +729,6 @@ create_qp_exit0:
static int prepare_sqe_rts(struct ehca_qp *my_qp, struct ehca_shca *shca,
int *bad_wqe_cnt)
{
- extern int ehca_debug_level;
u64 h_ret;
struct ipz_queue *squeue;
void *bad_send_wqe_p, *bad_send_wqe_v;
@@ -797,7 +797,6 @@ static int internal_modify_qp(struct ib_
struct ib_qp_attr *attr,
int attr_mask, int smi_reset2init)
{
- extern int ehca_debug_level;
enum ib_qp_state qp_cur_state, qp_new_state;
int cnt, qp_attr_idx, ret = 0;
enum ib_qp_statetrans statetrans;
@@ -807,7 +806,7 @@ static int internal_modify_qp(struct ib_
container_of(ibqp->pd->device, struct ehca_shca, ib_device);
u64 update_mask;
u64 h_ret;
- int bad_wqe_cnt;
+ int bad_wqe_cnt = 0;
int squeue_locked = 0;
unsigned long spl_flags = 0;
@@ -1253,7 +1251,6 @@ int ehca_query_qp(struct ib_qp *qp,
struct ib_qp_attr *qp_attr,
int qp_attr_mask, struct ib_qp_init_attr *qp_init_attr)
{
- extern int ehca_debug_level;
struct ehca_qp *my_qp = container_of(qp, struct ehca_qp, ib_qp);
struct ehca_pd *my_pd = container_of(my_qp->ib_qp.pd, struct ehca_pd,
ib_pd);
@@ -1410,7 +1407,6 @@ query_qp_exit1:
int ehca_destroy_qp(struct ib_qp *ibqp)
{
- extern struct ehca_module ehca_module;
struct ehca_qp *my_qp = container_of(ibqp, struct ehca_qp, ib_qp);
struct ehca_shca *shca = container_of(ibqp->device, struct ehca_shca,
ib_device);
@@ -1488,6 +1484,23 @@ int ehca_destroy_qp(struct ib_qp *ibqp)
ipz_queue_dtor(&my_qp->ipz_rqueue);
ipz_queue_dtor(&my_qp->ipz_squeue);
- kmem_cache_free(ehca_module.cache_qp, my_qp);
+ kmem_cache_free(qp_cache, my_qp);
return 0;
}
+
+int ehca_init_qp_cache(void)
+{
+ qp_cache = kmem_cache_create("ehca_cache_qp",
+ sizeof(struct ehca_qp), 0,
+ SLAB_HWCACHE_ALIGN,
+ NULL, NULL);
+ if (!qp_cache)
+ return -ENOMEM;
+ return 0;
+}
+
+void ehca_cleanup_qp_cache(void)
+{
+ if (qp_cache)
+ kmem_cache_destroy(qp_cache);
+}
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_reqs.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_reqs.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_reqs.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_reqs.c 2006-08-30
20:00:16.000000000 +0200
@@ -49,8 +49,6 @@
#include "hcp_if.h"
#include "hipz_fns.h"
-extern int ehca_debug_level;
-
static inline int ehca_write_rwqe(struct ipz_queue *ipz_rqueue,
struct ehca_wqe *wqe_p,
struct ib_recv_wr *recv_wr)
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ehca_sqp.c
infiniband_work/drivers/infiniband/hw/ehca/ehca_sqp.c
--- infiniband/drivers/infiniband/hw/ehca/ehca_sqp.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ehca_sqp.c 2006-08-30
20:00:16.000000000 +0200
@@ -49,8 +49,6 @@
#include "hcp_if.h"
-extern int ehca_port_act_time;
-
/**
* ehca_define_sqp - Defines special queue pair 1 (GSI QP). When special
queue
* pair is created successfully, the corresponding port gets active.
diff -Nurp infiniband/drivers/infiniband/hw/ehca/hcp_if.c
infiniband_work/drivers/infiniband/hw/ehca/hcp_if.c
--- infiniband/drivers/infiniband/hw/ehca/hcp_if.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/hcp_if.c 2006-08-30
20:00:17.000000000 +0200
@@ -410,7 +410,6 @@ u64 hipz_h_query_port(const struct ipz_a
const u8 port_id,
struct hipz_query_port *query_port_response_block)
{
- extern int ehca_debug_level;
u64 ret;
u64 dummy;
u64 r_cb = virt_to_abs(query_port_response_block);
diff -Nurp infiniband/drivers/infiniband/hw/ehca/hcp_phyp.h
infiniband_work/drivers/infiniband/hw/ehca/hcp_phyp.h
--- infiniband/drivers/infiniband/hw/ehca/hcp_phyp.h 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/hcp_phyp.h 2006-08-30
20:00:16.000000000 +0200
@@ -69,13 +69,13 @@ struct h_galpas {
static inline u64 hipz_galpa_load(struct h_galpa galpa, u32 offset)
{
u64 addr = galpa.fw_handle + offset;
- return *(u64 *)addr;
+ return *(volatile u64 __force *)addr;
}
static inline void hipz_galpa_store(struct h_galpa galpa, u32 offset, u64
value)
{
u64 addr = galpa.fw_handle + offset;
- *(u64 *)addr = value;
+ *(volatile u64 __force *)addr = value;
}
int hcp_galpas_ctor(struct h_galpas *galpas,
diff -Nurp infiniband/drivers/infiniband/hw/ehca/ipz_pt_fn.c
infiniband_work/drivers/infiniband/hw/ehca/ipz_pt_fn.c
--- infiniband/drivers/infiniband/hw/ehca/ipz_pt_fn.c 2006-08-30
18:02:01.000000000 +0200
+++ infiniband_work/drivers/infiniband/hw/ehca/ipz_pt_fn.c 2006-08-30
20:00:16.000000000 +0200
@@ -41,8 +41,6 @@
#include "ehca_tools.h"
#include "ipz_pt_fn.h"
-extern int ehca_hwlevel;
-
void *ipz_qpageit_get_inc(struct ipz_queue *queue)
{
void *ret = ipz_qeit_get(queue);
^ permalink raw reply
* Re: 2 Ethernet port operating in a PPC405EP system
From: Otto Solares @ 2006-08-30 18:23 UTC (permalink / raw)
To: Chun Chung Lo; +Cc: linuxppc-embedded
In-Reply-To: <A7B1E4DD46AA7046A4398F745240F29402737D5D@ASPROEXG.astri.local>
On Wed, Aug 30, 2006 at 09:17:20PM +0800, Chun Chung Lo wrote:
> I know my source code is vert old. But since there are lots of
> applications developed base on this 2 sets of source code, if the kernel
> and U-Boot needs to change, the above applications (tons of codes) also
> need to revise ... (lots of multimedia players, drivers, and other
> supporting tools). My team cannot afford such great change.
>
> So I say "update is not recommended" ...
Hopefully your product will say:
"buy this product is not recommended" :)
Don't repeat the same mistake as the MediaMVP, it uses the same
processor and same kernel version, it sucks badly...
-otto
^ permalink raw reply
* Re: PCIe enhanced configuration mechanism support on ppc arch
From: Arnd Bergmann @ 2006-08-30 18:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Milton Miller
In-Reply-To: <7cc604637892c0a00a5e3e38192494d7@bga.com>
On Wednesday 30 August 2006 18:30, Milton Miller wrote:
> The config access support is in arch/powerpc/kernel/rtas_pci.c,
> the setting of pci_ext_config_space is at arch/powerpc/kernel/pci_dn.c.
>
Well, so far that is only true for pseries and cell, as the others
normally don't use rtas for config space access.
Other platforms have their config space implementation in
arch/powerpc/platforms/<platform>/pci.c and may not support
this.
Arnd <><
^ permalink raw reply
* Re: [PATCH 4/6] Have x86_64 use add_active_range() and free_area_init_nodes
From: Keith Mannthey @ 2006-08-30 20:57 UTC (permalink / raw)
To: Mel Gorman
Cc: akpm, tony.luck, linuxppc-dev, ak, bob.picco, linux-kernel,
linux-mm
In-Reply-To: <20060821134638.22179.44471.sendpatchset@skynet.skynet.ie>
On 8/21/06, Mel Gorman <mel@csn.ul.ie> wrote:
>
> Size zones and holes in an architecture independent manner for x86_64.
Hey Mel,
I am having some trouble with the srat.c changes. I keep running into
"SRAT: Hotplug area has existing memory" so am am taking more throught
look at this patch.
I am working on 2.6.18-rc4-mm3 x86_64.
srat.c is doing some sanity checking against the e820 and hot-add
memory ranges. BIOS folk aren't to be trusted with the SRAT. Calling
remove_all_active_ranges before acpi_numa_init leaves nothing to fall
back onto if the SRAT is bad. (see bad_srat()). What should happen
when we discard the srat info?
i386 code may have similar fallback logic (haven't been there in a while)
also
> diff -rup -X /usr/src/patchset-0.6/bin//dontdiff linux-2.6.18-rc4-mm2-103-x86_use_init_nodes/arch/x86_64/mm/srat.c linux-2.6.18-rc4-mm2-104-x86_64_use_init_nodes/arch/x86_64/mm/srat.c
> --- linux-2.6.18-rc4-mm2-103-x86_use_init_nodes/arch/x86_64/mm/srat.c 2006-08-21 09:23:50.000000000 +0100
> +++ linux-2.6.18-rc4-mm2-104-x86_64_use_init_nodes/arch/x86_64/mm/srat.c 2006-08-21 10:15:58.000000000 +0100
> @@ -84,6 +84,7 @@ static __init void bad_srat(void)
> apicid_to_node[i] = NUMA_NO_NODE;
> for (i = 0; i < MAX_NUMNODES; i++)
> nodes_add[i].start = nodes[i].end = 0;
> + remove_all_active_ranges();
> }
We go back to setup_arch with no active areas?
> static __init inline int srat_disabled(void)
> @@ -166,7 +167,7 @@ static int hotadd_enough_memory(struct b
>
> if (mem < 0)
> return 0;
> - allowed = (end_pfn - e820_hole_size(0, end_pfn)) * PAGE_SIZE;
> + allowed = (end_pfn - absent_pages_in_range(0, end_pfn)) * PAGE_SIZE;
> allowed = (allowed / 100) * hotadd_percent;
> if (allocated + mem > allowed) {
> unsigned long range;
> @@ -238,7 +239,7 @@ static int reserve_hotadd(int node, unsi
> }
>
> /* This check might be a bit too strict, but I'm keeping it for now. */
> - if (e820_hole_size(s_pfn, e_pfn) != e_pfn - s_pfn) {
> + if (absent_pages_in_range(s_pfn, e_pfn) != e_pfn - s_pfn) {
> printk(KERN_ERR "SRAT: Hotplug area has existing memory\n");
> return -1;
> }
We really do want to to compare against the e820 map at it contains
the memory that is really present (this info was blown away before
acpi_numa) Anyway I fixed up to have the current chunk added
(e820_register_active_regions) after calling this code so it logicaly
makes sense but it still trip over the check. I am not sure what you
are printing out in you debug code but dosen't look like pfns or
phys_addresses but maybe it can tell us why the check fails.
> @@ -329,6 +330,8 @@ acpi_numa_memory_affinity_init(struct ac
>
> printk(KERN_INFO "SRAT: Node %u PXM %u %Lx-%Lx\n", node, pxm,
> nd->start, nd->end);
> + e820_register_active_regions(node, nd->start >> PAGE_SHIFT,
> + nd->end >> PAGE_SHIFT);
A node chunk in this section of code may be a hot-pluggable zone. With
MEMORY_HOTPLUG_SPARSE we don't want to register these regions.
> if (ma->flags.hot_pluggable && !reserve_hotadd(node, start, end) < 0) {
> /* Ignore hotadd region. Undo damage */
I have but the e820_register_active_regions as a else to this
statment the absent pages check fails.
Also nodes_cover_memory and alot of these check were based against
comparing the srat data against the e820. Now all this code is
comparing SRAT against SRAT....
I am willing to help here but we should compare the SRAT against to
e820. Table v. Table.
What to you think should be done?
Thanks,
Keith
Linux version 2.6.18-rc4-mm3-smp (root@elm3a153) (gcc version 4.1.0
(SUSE Linux)) #3 SMP Wed Aug 30 15:17:13 EDT 2006
Command line: root=/dev/sda3
ip=9.47.66.153:9.47.66.169:9.47.66.1:255.255.255.0 resume=/dev/sda2
showopts earlyprintk=ttyS0,115200 console=ttyS0,115200 console=tty0
debug numa=hotadd=100
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 0000000000098400 (usable)
BIOS-e820: 0000000000098400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000007ff85e00 (usable)
BIOS-e820: 000000007ff85e00 - 000000007ff98880 (ACPI data)
BIOS-e820: 000000007ff98880 - 0000000080000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 0000000470000000 (usable)
BIOS-e820: 0000001070000000 - 0000001160000000 (usable)
Entering add_active_range(0, 0, 152) 0 entries of 3200 used
Entering add_active_range(0, 256, 524165) 1 entries of 3200 used
Entering add_active_range(0, 1048576, 4653056) 2 entries of 3200 used
Entering add_active_range(0, 17235968, 18219008) 3 entries of 3200 used
end_pfn_map = 18219008
DMI 2.3 present.
ACPI: RSDP (v000 IBM ) @ 0x00000000000fdcf0
ACPI: RSDT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff98800
ACPI: FADT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff98780
ACPI: MADT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff98600
ACPI: SRAT (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff983c0
ACPI: HPET (v001 IBM EXA01ZEU 0x00001000 IBM 0x45444f43) @
0x000000007ff98380
ACPI: SSDT (v001 IBM VIGSSDT0 0x00001000 INTL 0x20030122) @
0x000000007ff90780
ACPI: SSDT (v001 IBM VIGSSDT1 0x00001000 INTL 0x20030122) @
0x000000007ff88bc0
ACPI: DSDT (v001 IBM EXA01ZEU 0x00001000 INTL 0x20030122) @
0x0000000000000000
SRAT: PXM 0 -> APIC 0 -> Node 0
SRAT: PXM 0 -> APIC 1 -> Node 0
SRAT: PXM 0 -> APIC 2 -> Node 0
SRAT: PXM 0 -> APIC 3 -> Node 0
SRAT: PXM 0 -> APIC 38 -> Node 0
SRAT: PXM 0 -> APIC 39 -> Node 0
SRAT: PXM 0 -> APIC 36 -> Node 0
SRAT: PXM 0 -> APIC 37 -> Node 0
SRAT: PXM 1 -> APIC 64 -> Node 1
SRAT: PXM 1 -> APIC 65 -> Node 1
SRAT: PXM 1 -> APIC 66 -> Node 1
SRAT: PXM 1 -> APIC 67 -> Node 1
SRAT: PXM 1 -> APIC 102 -> Node 1
SRAT: PXM 1 -> APIC 103 -> Node 1
SRAT: PXM 1 -> APIC 100 -> Node 1
SRAT: PXM 1 -> APIC 101 -> Node 1
SRAT: Node 0 PXM 0 0-80000000
Entering add_active_range(0, 0, 152) 0 entries of 3200 used
Entering add_active_range(0, 256, 524165) 1 entries of 3200 used
SRAT: Node 0 PXM 0 0-470000000
Entering add_active_range(0, 0, 152) 2 entries of 3200 used
Entering add_active_range(0, 256, 524165) 2 entries of 3200 used
Entering add_active_range(0, 1048576, 4653056) 2 entries of 3200 used
SRAT: Node 0 PXM 0 0-1070000000
SRAT: Hotplug area has existing memory
Entering add_active_range(0, 0, 152) 3 entries of 3200 used
Entering add_active_range(0, 256, 524165) 3 entries of 3200 used
Entering add_active_range(0, 1048576, 4653056) 3 entries of 3200 used
SRAT: Node 1 PXM 1 1070000000-1160000000
Entering add_active_range(1, 17235968, 18219008) 3 entries of 3200 used
SRAT: Node 1 PXM 1 1070000000-3200000000
SRAT: Hotplug area has existing memory
Entering add_active_range(1, 17235968, 18219008) 4 entries of 3200 used
NUMA: Using 28 for the hash shift.
Bootmem setup node 0 0000000000000000-0000001070000000
Bootmem setup node 1 0000001070000000-0000001160000000
^ permalink raw reply
* Re: libnuma interleaving oddness
From: Christoph Lameter @ 2006-08-30 21:04 UTC (permalink / raw)
To: Nishanth Aravamudan; +Cc: linux-mm, lnxninja, Andi Kleen, linuxppc-dev
In-Reply-To: <20060830072948.GE5195@us.ibm.com>
> I took out the mlock() call, and I get the same results, FWIW.
What zones are available on your box? Any with HIGHMEM?
Also what kernel version are we talking about? Before 2.6.18?
^ permalink raw reply
* Re: [PATCH] reboot when panic_timout is set
From: Mike Strosaker @ 2006-08-30 22:13 UTC (permalink / raw)
To: Olaf Hering; +Cc: linuxppc-dev, Paul Mackeras
In-Reply-To: <20060825201402.GA28214@aepfle.de>
Olaf Hering wrote:
>On Fri, Aug 25, Mike Strosaker wrote:
>
>>Olaf Hering wrote:
>>
>>
>>>Only call into RTAS when booted with panic=0 because the RTAS call does
>>>not return.
>>>The system has to be rebooted via the HMC or via the management console
>>>right now.
>>>This is cumbersome and not what the default panic=180 is supposed to do.
>>>
>>>
>>The os-term call is supposed to indicate to the platform that it should
>>follow it's abnormal OS termination policy. I normally set my
>>partitions to reboot immediately after an os-term call. I believe that
>>"/usr/sbin/serv_config -b" (installed with powerpc-utils-papr) is used
>>to set that policy from the command line.
>>
>>
>
>That doesnt help me at all if the kernel crashes before it reaches
>/init. And if one has to call a binary anyway to set or upgrade the
>policy, this binary can also set /proc/sys/kernel/panic to 0.
>
>
Hmm... I thought there was a way to modify the reboot policy from SMS or
the OF command line, but I can't find a way offhand. I'm trying to find
out from the firmware people here. It used to be an NVRAM variable in
one of the partitions visible to the OS (and so changable from OF with
the setenv command), but that's not the case anymore; it's now modified
by the ibm,set-system-parameter RTAS call.
>Do I have to set it for each boot, or is a change permanent?
>
>
The change is stored in NVRAM, and thus is persistent across reboots.
^ permalink raw reply
* Re: [QUESTION] Enable coherency for all pages on 83xx to fix PCI data corruption
From: Randy Vinson @ 2006-08-30 22:15 UTC (permalink / raw)
To: Liu Dave-r63238; +Cc: linuxppc-dev
In-Reply-To: <43765FEB-22D2-4435-A074-7DEF969E466B@kernel.crashing.org>
Kumar Gala wrote:
> Randy may remember but this fixed an issue related that he was seeing
> with an e100 or e1000 and it was the solution provided by the Freescale
> Apps team in Austin.
Hi All,
Sorry for the delay in responding, I've been out sick on and off.
The patch does not solve an erratum. It is required for proper operation if prefetching is enabled for any inbound PCI window.
The problem is related to the buffers in the I/O Sequencer (Page 11-1 of the MPC8349 Manual Rev 2). There are 12 of these buffers, each the length of a cache line. When memory prefetching is enabled for an inbound PCI window, these buffers can get pre-loaded with data from main memory. If the processor subsequently modifies this data in main memory and cache coherency is not enabled, the contents of the I/O Sequencer's buffers do not get snooped and stale data is delivered to the PCI bus. If memory coherency is enabled, subsequent writes to pre-fetchable memory are snooped by the I/O Sequencer and the stale data problem is avoided.
The connection to PCI erratum 5 was false. Marking the inbound PCI memory windows non-prefetchable solved the problem because the I/O Sequencers internal buffers were not pre-loaded and could not contain stale data.
Kumar is correct in that the solution was provided by the folks at Freescale. Similar corruption has been seen when using a MPC107 host bridge with 74[45]x processors as the MPC107 also has an internal set of buffers that can contain stale data if prefetching is enabled on inbound PCI windows. In fact, there is a comment to that effect just above the comment adding the 83xx in the patch.
Randy V.
^ permalink raw reply
* Re: PCIe enhanced configuration mechanism support on ppc arch
From: Benjamin Herrenschmidt @ 2006-08-30 23:03 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <7cc604637892c0a00a5e3e38192494d7@bga.com>
On Wed, 2006-08-30 at 11:30 -0500, Milton Miller wrote:
> On Fri Aug 18 05:01:48 EST 2006, Shawn Jin wrote:
> > I'm trying to find out if the current PCI subsystem supports the PCIe
> > enhanced configuration mechanism, in particular, on the ppc/powerpc
> > arch, which is basically a MMIO access with the address containing all
> > bus, device, function, and offset info.
>
> If what you are really trying to find is the 4k extended config space,
> then there are some platforms that support that on some slots.
>
> If you are trying to find the mmio address for your adapter, then the
> answer is I am not aware of any PowerPC platforms that provide that,
> although I am not familiar with the embedded processor platforms nor
> the pci express Apple boxes.
>
> > Could someone here give an authoritative answer? Or point me to
> > somewhere I can look for it by myself, such as which file or directory
> > in the kernel tree. I searched at arch/ppc/kernel,
> > arch/powerpc/kernel, and drivers/pci but couldn't find an answer. :(
>
> The config access support is in arch/powerpc/kernel/rtas_pci.c,
> the setting of pci_ext_config_space is at arch/powerpc/kernel/pci_dn.c.
Actually, that only sets the variable used by the RTAS PCI accessors.
Other platforms might do differently. The PCI probe code uses the
generic pci_cfg_space_size() function to determine wether extended
config space is supported for a given device.
An example of platform not using RTAS and that does support extended
config space is the PCI Express link out of the U4 northbridge on
PowerMac (though not the other PCIe slots connected to the HT<->PCIe
tunnel, at least not for now).
It's basically just a matter of having your low level config access
routines supporting those >=256 offsets. The generic code tests that by
doing a dummy access and checks for an error return.
Ben.
^ permalink raw reply
* RE: DS1302 driver for powerpc
From: Chun Chung Lo @ 2006-08-31 0:51 UTC (permalink / raw)
To: Matt Porter; +Cc: linuxppc-embedded
Hi,
Thanks for your help.
But I also do not have this driver for 83xx. (as my linux is comes from
Montavista)
Could you mind providing me a link / or a source of such driver for me
to reference ?
Thanks.
Best regards,
Lo Chun Chung
-----Original Message-----
From: Matt Porter [mailto:mporter@embeddedalley.com]=0D
Sent: Wednesday, 30 August, 2006 9:55 PM
To: Chun Chung Lo
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: DS1302 driver for powerpc
On Wed, Aug 30, 2006 at 07:54:16PM +0800, Chun Chung Lo wrote:
>=0D
> Hi all,
>=0D
> I am now doing a STB project and the development board uses a DS1302=0D
> (trickle charge timekeeping chip) as a RTC. Our board is a IBM=0D
> PPC405EP with a linux kernel 2.4.20 running on it. And the DS1302 is=0D
> controlled by 2 GPIO pins instead of I2C.
>=0D
> I would like to ask are there any porting of DS1302 support under ppc=0D
> architecture? (I can only find DS1302 is supported under cris
> architecture.)
There doesn't seem to be any DS1302 support "for ppc" available.
However, even if there were a platform with DS1302 support you'd be in
the same boat as the low-level support for cris. Support for DS1302 has
a glue layer that's board-specific based on what GPIO pins are used to
drive it. So if you had this driver for another PPC system like 83xx
you'd still have no better starting point than the cris ds1302 driver
glue since the GPIO mechanism/connection is different. Porting the
board-specific glue from arch/cris/drivers/ds1302.c to 4xx GPIO is
trivial to do though.
-Matt
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* RE: 2 Ethernet port operating in a PPC405EP system
From: Chun Chung Lo @ 2006-08-31 0:54 UTC (permalink / raw)
To: Otto Solares; +Cc: linuxppc-embedded
Hi,
I really do not know what happened about MediaMVP, could you mind giving
me a review?
Thanks.
Best regards,
Lo Chun Chung
-----Original Message-----
From: Otto Solares [mailto:solca@guug.org]=0D
Sent: Thursday, 31 August, 2006 2:23 AM
To: Chun Chung Lo
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: 2 Ethernet port operating in a PPC405EP system
On Wed, Aug 30, 2006 at 09:17:20PM +0800, Chun Chung Lo wrote:
> I know my source code is vert old. But since there are lots of=0D
> applications developed base on this 2 sets of source code, if the=0D
> kernel and U-Boot needs to change, the above applications (tons of=0D
> codes) also need to revise ... (lots of multimedia players, drivers,=0D
> and other supporting tools). My team cannot afford such great change.
>=0D
> So I say "update is not recommended" ...
Hopefully your product will say:
"buy this product is not recommended" :)
Don't repeat the same mistake as the MediaMVP, it uses the same
processor and same kernel version, it sucks badly...
-otto
This message (including any attachments) is for the named addressee(s)'s=
use only. It may contain
sensitive, confidential, private proprietary or legally privileged=
information intended for a
specific individual and purpose, and is protected by law. If you are not=
the intended recipient,
please immediately delete it and all copies of it from your system, destroy=
any hard copies of it
and notify the sender. Any use, disclosure, copying, or distribution of=
this message and/or any
attachments is strictly prohibited.
^ permalink raw reply
* Re: IPSec kernel oops on ppc64
From: Paul Mackerras @ 2006-08-31 0:57 UTC (permalink / raw)
To: Joy Latten; +Cc: jmorris, herbert, netdev, anton, linuxppc-dev, gcwilson, davem
In-Reply-To: <200608301636.k7UGaQY5002569@faith.austin.ibm.com>
Joy Latten writes:
> The good news is that the pings worked great!
> So perhaps ESP is working ok with ICMP.
>
> But when I tried to do sftp, I still got the oops.
> I don't think TCP and ESP are working.
You're hitting the BUG_ON(len) at line 611 of net/xfrm/xfrm_algo.c.
Is that the same thing that happened without the patch to memcpy, or
was that a different oops?
Paul.
^ 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