* Re: How to turn off MMU in MPC8540
From: Kumar Gala @ 2006-08-30 13:31 UTC (permalink / raw)
To: Reddy Suneel-ASR125; +Cc: linuxppc-embedded
In-Reply-To: <405ECA8A30557F439A723E52D50838F9D8295F@ZMY16EXM66.ds.mot.com>
On Aug 30, 2006, at 1:25 AM, Reddy Suneel-ASR125 wrote:
> Hi
>
> Can anyone know how to turn off MMU in MPC8540?
You can not turn the MMU off on the MPC8540 or any e500 based
product. You can emulate a 1:1 mapping if you so desire by
preloading TLBs.
- kumar
^ permalink raw reply
* Re: DS1302 driver for powerpc
From: Matt Porter @ 2006-08-30 13:55 UTC (permalink / raw)
To: Chun Chung Lo; +Cc: linuxppc-embedded
In-Reply-To: <A7B1E4DD46AA7046A4398F745240F29402737D5B@ASPROEXG.astri.local>
On Wed, Aug 30, 2006 at 07:54:16PM +0800, Chun Chung Lo wrote:
>
> Hi all,
>
> I am now doing a STB project and the development board uses a DS1302
> (trickle charge timekeeping chip) as a RTC. Our board is a IBM PPC405EP
> with a linux kernel 2.4.20 running on it. And the DS1302 is controlled
> by 2 GPIO pins instead of I2C.
>
> I would like to ask are there any porting of DS1302 support under ppc
> 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
^ permalink raw reply
* could not access the address in linux-System ace driver
From: sudheer @ 2006-08-30 14:12 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: raja_chidambaram82
In-Reply-To: <44EB1DC2.5070307@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12198 bytes --]
Hello All
I'm really desperate for some help , I've been struggling with this
system since few days.
sudheer wrote:
> Hello Raja,
>
> We too are working on customized board with amcc 440SPe processor ,
> xilinx System Ace controller. Compact flash is connected to system
> ace controller.
> We use u-boot 1.1.2 as bootloader & linux kernel - 2.6.16-2.
>
> System ace is connected to amcc440SPE processor via GPIO and External
> Peripheral Bus Controller(EBC).
I am still facing the issue in accessing the address in linux.
The physical address given in u-boot init.S tlbentry for 'system ace'
is 0xE0000000
I am able to access the address in u-boot and everything is fine in u-boot.
But in linux , I am able to ioremap the the address 0xE0000000 but the
kernel crashes when i try to access the address .
physical address=0xe0000000
address_after_ioremap = 0xe1000000.
I am trying to read with readw(address_after_ioremap)
The kernel gives an exception error saying Oops: machine check, sig: 7
[#2] .
The error dump is as below:
Instruction dump:
Data machine check in kernel mode.
PLB0: BEAR=0x00000000e0000000 ACR= 0xdb000000 BESR= 0x0000000000008000
PLB1: BEAR=0xe98d7ad33716ee7e ACR= 0xdb000000 BESR= 0x0000000000000000
POB0: BEAR=0x0000000fffaebbcd BESR0=0x00000000 BESR1=0x00000000
OPB0: BEAR=0x0000000000000000 BSTAT=0x00000000
Oops: machine check, sig: 7 [#2]
NIP: 00000000 LR: C0002200 CTR: 00000000
REGS: c0241f50 TRAP: 0202 Not tainted (2.6.16.2)
MSR: 00000000 <> CR: 84CA4124 XER: 00000000
TASK = dff6cb70[1] 'swapper' THREAD: c0740000
GPR00: 00000000 C0241E40 DFF6CB70 00000001 FFFFFFD0 00000000 C0240000
C01F3C0C
GPR08: C01F0000 C0002200 00021002 C0001FF4 DFF6CD38 802823E0 1FFB9600
00000000
GPR16: 00000001 FFFFFFFF 00000000 007FFF00 1FFB3540 1FF63CE0 1FFCEE78
C01C0000
GPR24: C01C0000 C01C0000 C01F0000 C01C0000 BFFFFFFF FFFFFFD0 00000000
C0241F50
NIP [00000000] 0x0
LR [C0002200] ret_from_except+0x0/0x18
Call Trace:
Instruction dump:
Data machine check in kernel mode.
PLB0: BEAR=0x00000000e0000000 ACR= 0xdb000000 BESR= 0x0000000000008000
.........and this dump gets print continously.
I have checked with TLB entries in u-boot and linux using BDI:
BDI_AMCC440SPe>tlb 0 10
IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
0 : 00 ff000000 16MB V0 -> 4_ff000000 U:0000 WI-G- XWRXWR
1 : 00 00000000 256MB V0 -> 0_00000000 U:0000 -I-G- XWRXWR
2 : 00 10000000 256MB V0 -> 0_10000000 U:0000 -I-G- XWRXWR
3 : 00 20000000 256MB V0 -> 0_20000000 U:0000 -I-G- XWRXWR
4 : 00 30000000 256MB V0 -> 0_30000000 U:0000 -I-G- XWRXWR
5 : 00 90000000 256KB V0 -> 4_00000000 U:0000 -I--- XWRXWR
6 : 00 e0000000 1KB V0 -> 4_e0000000 U:0000 -I-G- -WR-WR
7 : 00 a0000000 4KB V0 -> 4_f0000000 U:0000 -I-G- -WR-WR
8 : 00 d0000000 256MB V0 -> c_00000000 U:0000 -I-G- -WR-WR
9 : 00 80000000 256MB V0 -> c_10000000 U:0000 -I-G- -WR-WR
10 : 00 01080000 1KB -0 -> 0_00000000 U:0000 ----- ------
BDI_AMCC440SPe>
In Linux the tlb entries are as below.......
BDI_AMCC440SPe>tlb 0 63
IDX TID EPN SIZE VTS RPN USER WIMGE USRSVC
0 : 0e 0ff1a000 4KB V0 -> 0_007ce000 U:0000 --MG- --R--R
1 : 0e 0fe94000 4KB V0 -> 0_1ff96000 U:0000 ---G- X-RX-R
2 : 0e 30017000 4KB V0 -> 0_007cd000 U:0000 --MG- --R-WR
3 : 0e 10039000 4KB V0 -> 0_1ffb8000 U:0000 ---G- X-RX-R
4 : 0e 30009000 4KB V0 -> 0_00758000 U:0000 ---G- X-RX-R
5 : 0e 30010000 4KB V0 -> 0_0078b000 U:0000 ---G- X-RX-R
6 : 0e 00000000 1KB -0 -> 0_1f4e2000 U:0000 ---G- --R--R
7 : 0e 0fe3e000 4KB V0 -> 0_1f4e2000 U:0000 ---G- X-RX-R
8 : 0e 0ff1c000 4KB V0 -> 0_007ed000 U:0000 --MG- XWRXWR
9 : 0e 0ff1e000 4KB V0 -> 0_007ee000 U:0000 --MG- -WR-WR
10 : 0e 0ff1f000 4KB V0 -> 0_007ea000 U:0000 --MG- XWRXWR
11 : 0e 0fe39000 4KB V0 -> 0_1ff8e000 U:0000 ---G- X-RX-R
12 : 0e 0ff21000 4KB V0 -> 0_007a8000 U:0000 --MG- --R-WR
13 : 0e 0fe47000 4KB V0 -> 0_1ffa9000 U:0000 ---G- X-RX-R
14 : 0e 0fe46000 4KB V0 -> 0_1ffb2000 U:0000 ---G- X-RX-R
15 : 0e 30019000 4KB V0 -> 0_007c5000 U:0000 --MG- -WR-WR
16 : 0e 0fe45000 4KB V0 -> 0_1ffa8000 U:0000 ---G- X-RX-R
17 : 00 fdfff000 4KB V0 -> 4_f0000000 U:0000 -IMG- ----WR
18 : 0e 0fe9a000 4KB V0 -> 0_1ff98000 U:0000 ---G- X-RX-R
19 : 0e 10067000 4KB V0 -> 0_0078e000 U:0000 --MG- -WR-WR
20 : 0e 00000000 4KB -0 -> 0_1f4e5000 U:0000 ---G- --R--R
21 : 0e 10030000 4KB V0 -> 0_1f4e5000 U:0000 ---G- X-RX-R
22 : 0e 10063000 4KB V0 -> 0_007b7000 U:0000 --MG- -WR-WR
23 : 0e 0fe4c000 4KB V0 -> 0_1ff9b000 U:0000 ---G- X-RX-R
24 : 0e 1007f000 4KB V0 -> 0_007e0000 U:0000 --MG- -WR-WR
25 : 0e 0ff1d000 4KB V0 -> 0_007c6000 U:0000 --MG- --R-WR
26 : 0e 0fe4e000 4KB V0 -> 0_1ffa1000 U:0000 ---G- X-RX-R
27 : 0e 0fe0f000 4KB V0 -> 0_0077e000 U:0000 ---G- X-RX-R
28 : 0e 0fe52000 4KB V0 -> 0_0077f000 U:0000 ---G- X-RX-R
29 : 0e 0fe53000 4KB V0 -> 0_1ff80000 U:0000 ---G- X-RX-R
30 : 0e 0fef9000 4KB V0 -> 0_1ff81000 U:0000 ---G- --R--R
31 : 0e 0fe3b000 4KB V0 -> 0_1ffa7000 U:0000 ---G- X-RX-R
32 : 0e 7f901000 4KB V0 -> 0_007db000 U:0000 --MG- -WR-WR
33 : 0e 10027000 4KB V0 -> 0_1ffd0000 U:0000 ---G- X-RX-R
34 : 0e 1003a000 4KB V0 -> 0_1ffb6000 U:0000 ---G- X-RX-R
35 : 0e 0fe51000 4KB V0 -> 0_00775000 U:0000 ---G- X-RX-R
36 : 0e 1003b000 4KB V0 -> 0_1ffb7000 U:0000 ---G- X-RX-R
37 : 0e 1002a000 4KB V0 -> 0_1ffcf000 U:0000 ---G- X-RX-R
38 : 0e 10066000 4KB V0 -> 0_007de000 U:0000 --MG- -WR-WR
39 : 0e 1002b000 4KB V0 -> 0_1ffd3000 U:0000 ---G- X-RX-R
40 : 0e 1002c000 4KB V0 -> 0_1ffd2000 U:0000 ---G- X-RX-R
41 : 0e 1005d000 4KB V0 -> 0_007f4000 U:0000 --MG- XWRXWR
42 : 0e 1002d000 4KB V0 -> 0_1ffc2000 U:0000 ---G- X-RX-R
43 : 0e 10028000 4KB V0 -> 0_1ffc8000 U:0000 ---G- X-RX-R
44 : 0e 10069000 4KB V0 -> 0_0078d000 U:0000 --MG- -WR-WR
45 : 0e 1002e000 4KB V0 -> 0_1ffd4000 U:0000 ---G- X-RX-R
46 : 0e 1005e000 4KB V0 -> 0_007a7000 U:0000 --MG- X-RXWR
47 : 0e 0fe11000 4KB V0 -> 0_0077a000 U:0000 ---G- X-RX-R
48 : 0e 10047000 4KB V0 -> 0_1ffcd000 U:0000 ---G- --R--R
49 : 0e 1007e000 4KB V0 -> 0_007d0000 U:0000 --MG- --R-WR
50 : 0e 0fea1000 4KB V0 -> 0_1ffd5000 U:0000 ---G- X-RX-R
51 : 0e 10026000 4KB V0 -> 0_1ffc9000 U:0000 ---G- X-RX-R
52 : 0e 0fe0e000 4KB V0 -> 0_1ffd1000 U:0000 ---G- X-RX-R
53 : 0e 0fe96000 4KB V0 -> 0_1ffce000 U:0000 ---G- X-RX-R
54 : 0e 1002f000 4KB V0 -> 0_1f4c1000 U:0000 ---G- X-RX-R
55 : 0e 7f900000 4KB V0 -> 0_0078f000 U:0000 --MG- -WR-WR
56 : 0e 10036000 4KB V0 -> 0_1f4c0000 U:0000 ---G- X-RX-R
57 : 0e 1004b000 4KB V0 -> 0_1ffcc000 U:0000 ---G- --R--R
58 : 0e 0fe9b000 4KB V0 -> 0_1ff88000 U:0000 ---G- X-RX-R
59 : 0e 0fe4d000 4KB V0 -> 0_1ffa0000 U:0000 ---G- X-RX-R
60 : 0e 10080000 4KB V0 -> 0_00793000 U:0000 --MG- -WR-WR
61 : 0e 0fe95000 4KB V0 -> 0_1ff99000 U:0000 ---G- X-RX-R
62 : 00 d0000000 256MB V0 -> 0_10000000 U:0000 ---G- ---XWR
63 : 00 c0000000 256MB V0 -> 0_00000000 U:0000 ---G- ---XWR
BDI_AMCC440SPe>
I could not see the tlb entry for system ace in the linux level, But in
the kernel error message, the physical address address can be seen
EBC's BEAR=0x00000000e0000000 saying the ioremap is done properly and
phys-addr is obtaining from virtual adr given.
I could not understand what is going wrong. When i try to read/write
using the ioremapped address, the kernel crashes. Even from the
Error/Status reg(EBC's BESR in the error dump) could not get any
information.
Can someone please be so kind to help me debug this...what might be
wrong / what should I do to try and get a better understanding of what
is going wrong?
please let me if any details required.
Thank you in advance
Regards
Sudheer
>
> While booting the linux, it crashes when i am trying to
> access(read/write) a system ace register.
> In the u-boot though i have support, as of now i am not doing
> anything with system ace as it not required now.
> In u-boot/include/configs/custom_board.h, i could see
> #define CFG_ACE_BASE 0xe0000000 /* Xilinx ACE
> controller - Compact Flash */
> So i have used this address in Linux driver to to ioremap to access
> the ace registers. Though i could do ioremap, it crashes while
> booting exactly when it is trying the access any ace register.
>
> I doubt with the address i have used . But could not get any clue from
> the docs given.
>
> I want to know how to access the system ace registers and how to get
> the address to ioremap. Please let me know if any details required and
> also if i am missing any fundamentals.
>
>
> Thanks & Regards
> Sudheer
>
>
>
>
> sudheer wrote:
>> Hi Ameet,
>>
>> Firstly, thanks for the mail.
>>
>> I am able to compile the linux-2.6.16 and got the ace support files with
>> the patch.
>> While compiling got some errors with xparameters, but am rectify them.
>>
>> I need to wait for the hardware to test the source.
>>
>> Thanks & Regards
>> Sudheer
>>
>>
>> Ameet Patil wrote:
>>
>>> Hi Sudheer,
>>> Frank has already answered your questions. If you have any problems
>>> with the SysAce patch... do let me know. I have written a small
>>> tutorial here if it helps...
>>>
>>> http://linux.get2knowmore.com
>>>
>>>
>>> -Ameet
>>>
>>> sudheer wrote:
>>>
>>>> Hello Ameet Patil
>>>>
>>>> I am looking for linux kernel source 2.6.16 with system ace
>>>> controller support. I downloaded the linux-2.6.16 and linux-2.6.17-1
>>>> source from kernel.org but could not find any files related to system
>>>> ace controller ( No xilinx_sysace directory in drivers/block/) . I
>>>> have checked penguinppc.org also but could not get it.
>>>>
>>>> Can you please send to me the link where i could download the
>>>> linuxppc-2.6.16 source with system ace support.
>>>>
>>>> Thanks & Regards
>>>> Sudheer
>>>>
>>>> Ameet Patil wrote:
>>>>
>>>>> Hi Raja,
>>>>> I have ported the Xilinx System ACE driver to 2.6 kernel. Find
>>>>> the latest one here:
>>>>> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.2.patch
>>>>>
>>>>>
>>>>> NOTE: this patch wouldn't work if you are using the TEMAC driver. In
>>>>> which case use the -after-TEMAC patch found in the patches folder
>>>>> above.
>>>>>
>>>>> Check the following discussions (threads) for more details:
>>>>> 1. "Xilinx SystemACE driver for 2.6"
>>>>> 2. "Xilinx BSP for linux 2.6"
>>>>> 3. "Kernel hangs after "Now booting the kernel"."
>>>>>
>>>>> cheers,
>>>>> -Ameet
>>>>>
>>>>> Raja Chidambaram wrote:
>>>>>
>>>>>
>>>>>> Hi all,
>>>>>> We are working on customized board with amcc 440SPe
>>>>>> processor & xilinx System Ace controller. The System
>>>>>> Ace controller is connected to compact flash driver.
>>>>>>
>>>>>> We use u-boot 1.2 as bootloader & linux kernel
>>>>>> 2.6.16-2.
>>>>>>
>>>>>> On the process the u-boot is able to detect compact
>>>>>> flash through Xilinx SystemAce controller & able to
>>>>>> load the kernel image into compact flash.But when the
>>>>>> linux boot's up it not able to detect the System Ace
>>>>>> controller or compact flash.
>>>>>>
>>>>>> Note:we need to have the root file system in compact
>>>>>> flash.
>>>>>>
>>>>>> Is their any drivers available for SystemAce
>>>>>> controller on linux 2.6,if their how to get it.please
>>>>>> help me in this
>>>>>> with regards
>>>>>> raja
>>>>>>
>>>>>>
>>>>>>
>>>>>> __________________________________________________
>>>>>> Do You Yahoo!?
>>>>>> Tired of spam? Yahoo! Mail has the best spam protection around
>>>>>> http://mail.yahoo.com _______________________________________________
>>>>>> Linuxppc-embedded mailing list
>>>>>> Linuxppc-embedded@ozlabs.org
>>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Linuxppc-embedded mailing list
>>>>> Linuxppc-embedded@ozlabs.org
>>>>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>>>>
>>>>>
>>>>>
>> _______________________________________________
>> Linuxppc-embedded mailing list
>> Linuxppc-embedded@ozlabs.org
>> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 15380 bytes --]
^ permalink raw reply
* 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
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