| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Change-Id: I55e07062e18bf8652752914151f640dce1a1623e
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4744
Tested-by: Jenkins Server
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: ADAM R. MUHLE <armuhle@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
RTC: 71081
Change-Id: Ic5531fbba92cfc7aad7d303f043d6a350483d63d
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4607
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I0dc57ec047beb47b557b816162d619a5b2a54108
RTC: 64619
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4600
Tested-by: Jenkins Server
Reviewed-by: ADAM R. MUHLE <armuhle@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
RTC: 63128
Change-Id: Ica27c7f714bc8b874c9bccb663a32d3cfba37c5a
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4193
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously the heap coalesce function looked at the "free" flag
on the next block to determine if two blocks could be merged
together. The coalesce function is ran with all cores synchronized
so no one should be modifying the heap, but there is still a
subtle race condition.
A user task could be in the process of freeing a block, marking it
"free" but not actually inserting it onto the queues yet. The
coalesce will combine this block together but then when the user
task resumes it continues to try to insert it onto the queue.
This causes both the larger merged block and the smaller block to
be on a free queue and memory corruption when both blocks are used.
This is resolved by having a new flag indicating that the block
is known to be part of the "coalesce" group and using this in
addition to the "free" flag. Only blocks which are actually present
on the free queues are considered to be part of the "coalesce"
group.
Change-Id: If33d15d731d32e07e01104244ebc65daf2295878
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4520
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commit updates IBSCOM to have error path support.
It also updates the good-path test cases since there is
limited good path support in simics. Full enablement
will be done later.
Change-Id: I5f9d66165db119473f606303a1026c8c71988785
RTC: 34743
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/3972
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I25ec156fe3c9088d2de2254017407dbadd2fac31
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4255
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I859f94234d5672f55f745dd37b9662c310b694a7
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4236
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The interrupt handling was originally written with the intent
that only a single thread would receive interrupts. We
purposefully program the Interrupt Presenter hardware to
route all interrupts to a single core.
IPIs (Inter-processor Interrupts) are not routable by the ICP
and end up being delivered to the targeted thread. When we
trigger a winkle-wakeup of a thread, that thread gets the IPI
interrupt. Since we broadcast the IPI to all threads on a core
there is potential for multiple threads to be using the interrupt
object at once. Hence, we added a spinlock to protect it.
Change-Id: I736de774496b13cc9f344d389b9f249bbabeb036
Tested-by: Jenkins Server
Reviewed-by: Dean Sanner <dsanner@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: I1d357cedbd0dc77f2cde0d9071a82860398e09b6
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4096
Tested-by: Jenkins Server
Reviewed-by: Dean Sanner <dsanner@us.ibm.com>
Reviewed-by: ADAM R. MUHLE <armuhle@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
| |
Change-Id: Ief0b9202e13bd70cf0de84ca3cb20f5c6df4d3d8
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/4035
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
RTC: 63124
Change-Id: I1ad1d6bdf6a2848b686b25504fabddddb701d440
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/3813
Tested-by: Jenkins Server
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: Michael Baiocchi <baiocchi@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: I5ac1b8e64320068822debeb33fbc54469f6ac232
RTC: 44523
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/3133
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
| |
RTC:64829
Change-Id: Ic8e7983f6838b79c359c4cee2647b7676493cb1e
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/3564
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Ifbfa8dce23f6ec086863bf83c1e5ae9e39dcc48a
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/3394
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
Modified anywhere that we enable non-master threads to only
touch the threads that we are told to update.
Change-Id: I5b764e51d85a5c663ac76164e9465831ef0c167c
RTC: 48808
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2877
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Updating the doShutdown path to support receiving a reason
code as input. Then changing PNOR RP to issue a shutdown
when problems are detected with the PNOR Partition table.
RTC: 44146
Change-Id: Ib4111d0a91f53d90fa100422a1463539897598e6
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/3024
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
| |
Change-Id: I5a185aa5ac86a70361b43e71ad264bee87aea2d0
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2956
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The coalesce was causing time issues in VPO.
Reduce from an O(n^2) to O(n) algorithm.
Results from one particular execution:
- Old - 91649004 cycles for 7471 chunks
- New - 02668146 cycles for 7676 chunks
<3% cycle time of original algorithm.
Change-Id: I7145c6b430dccdb3f08d186a1ee5ea2f86aa3f81
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2942
Tested-by: Jenkins Server
Reviewed-by: Van H. Lee <vanlee@us.ibm.com>
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: Thi N. Tran <thi@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For P8 the priority of different threads has no effect unless the
relative priority register is programmed to tell the relative
scheduling weight of the different priorities.
We will now be programming the RPR to give 32x performance boost
to "high" priority threads relative to "low" priority. This
means that when a thread is waiting on another, and thus has low
priority, it will get 32x less dispatch cycles then the thread
it is waiting on.
Change-Id: I0d1d1052b12ab8bd5612aa4580cd85b5c238f885
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2888
Tested-by: Jenkins Server
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: Mark W. Wenning <wenning@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I9186f42f85d6f6864b51b6935f5d4e5ca510ceb4
RTC: 39872
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2901
Tested-by: Jenkins Server
Reviewed-by: ADAM R. MUHLE <armuhle@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I0ac43ab3eaeb5dfb9edc626a5a41e553988ec926
RTC: 52972
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2736
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Added a new access type of BYPASS_HRMOR that the ptmgr will
support when a PTE is added, so that blocks can support
addresses which do not have the HRMOR applied.
This is needed so that mm_linear_map will work correctly when
HRMOR != 0.
Change-Id: Ie4599d63a4454f425e0a0964b02fec7075c4401e
RTC: 60665
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2733
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I5d95f3e3e2d803f07c7d8f3bf2d8ee522e1b4519
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2406
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
|
|
|
|
|
|
|
|
|
| |
RTC: 35396
Change-Id: I96ea0d95606f04abb4dc2b0470345ca475b53912
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2520
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implemented functions to load the Host Interface Data
into memory and retrieve pointers to specific pieces
of data therein.
Verified in Murano and Tuleta configs.
RTC: 49509
Change-Id: I18b44cd53f2cab91b83ecad283b998783e275d4f
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2367
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: Terry J. Opie <opiet@us.ibm.com>
Reviewed-by: Melissa J. Connell <missyc@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Disabling the page castout test because it happens anyway already
and it takes a long time with all of the mainstore space we have
now. I also fixed a missed todo in ptmgr related to expanding
into mainstore.
Change-Id: I9d2027a13cc968ab33c0d5a61d5023b6cebc9add
RTC: 37748
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2371
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If fake PNOR isn't being used, we can expand our memory space to
the full 8MB cache. There will be follow up work with RTC: 49137
to support 4MB degraded caches for bring-up.
Change-Id: I1248efa37965f39ebab62aae556349c34aa24b66
RTC: 47356
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2319
Tested-by: Jenkins Server
Reviewed-by: Melissa J. Connell <missyc@us.ibm.com>
Reviewed-by: ADAM R. MUHLE <armuhle@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
Change-Id: I37c8956afb11c69201f4936821cff5e153327780
RTC:43793
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2194
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: Ic5cb0817118bf0de7d706124708e5b8551ba4258
RTC: 41425
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1899
Tested-by: Jenkins Server
Reviewed-by: Van H. Lee <vanlee@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
- Add include files into the fsp.tar
Change-Id: I12a50f7e09f70b1bc6acf436d896b6f3747a7507
RTC:50578
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2115
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Idb7a2d8d72a55f644efd0b2548eca5df5d062e6d
RTC: 47491
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/2011
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add mmLinearMap to create block at a specified phys addr.
Added iv_MaptoPhy in the block to indicate we are physically mapped
block and to not apply the HRMOR.
Change-Id: I75ddb19b82ae9a2035ff873edff8a34a33c74639
RTC:43401
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1846
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
Change-Id: Ib234df5b96275b0174994712d5b250681625f148
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1928
Tested-by: Jenkins Server
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I196e58be48195f653ab16a74dedafabafbd07bbc
RTC: 47013
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1774
Tested-by: Jenkins Server
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The memory profiling tools sometimes encountered a condition where
the kernel stack was becoming corrupted. I tracked it down to the
winkle code storing the winkle-save state at the wrong end of the
stack. Moving the winkle-save area to the bottom of the stack,
which is where I originally intended it to go.
Also noticed that the task issuing the winkle was in "running"
state while waiting for the cores to come out of winkle. Ensure
that the kernel updates the task state with a non-running status
while we are waiting for winkle to complete.
Change-Id: I07a56ea6f24cbc09362f9227d81915da5bc9f148
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1737
Tested-by: Jenkins Server
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes to kernel code to support detection and use of HRMOR
offset in memory
Changes to tooling to handle the real memory offset
New interface to retrieve the physical address that
corresponds to a virtual address
To test, run these commands before starting up Hostboot:
system_cmp0.cpu0_0_05_0.write-reg HRMOR 0x8000000
proc_venicechip_cmp0.phys_mem.del-map p8Proc0.l3_cache_ram 0 0
RTC: 46032
Change-Id: I50ab248f941218a3a14a8f0fc12a551b56dc7cf3
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1553
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When executing the nap instruction, all thread state can be
lost. This was causing r0 to be lost, which contained the
system-call number for the idle thread to request permission
to execute nap and as a result 'task-yield' was executed
instead of 'cpu-nap' after the idle thread took its first
nap.
Re-arranged the sreset code that handles nap-wakeup to deal
with thread-state being lost when entering nap and instead
using the previously saved task-state from the 'cpu-nap'
system call.
Change-Id: Id7468a8577c4d7b273b23bc97e7dd040555e7b67
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1567
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Created per-node arrays of CPU objects rather than a single array
for the entire system. These are created dynamically as CPUs are
enabled.
Also disabled support for P7 due to the PIR layout being different
and hence would have needed two different sets of assembly code.
We have been running exclusively on the P8 Mambo model for a while.
RTC: 42815
Change-Id: Ib92de8a7c07c2e700a3b7f0c03c64d484b447ca2
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1630
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Power processor has instructions of the form 'or a,a,a'
that allow code to change the priority of a hw-thread relative
to the others. We initially used 'or 1,1,1' as low priority
and 'or 3,3,3' as high priority. This is used in, for instance,
spinlocks to reduce the priority of a hw-thread while waiting
for another thread to perform an activity.
This code originally came from HAL. In reading the Power ISA
closer I realized that 'or 3,3,3' has no effect when in
user-space code, which means that a spinlock-like effect in
user code is going to end up with the thread stuck at low
priority until the next context switch. To prevent this we
are going to change from 1/3 to 1/2 as the priority levels.
Change-Id: I60ee866cde37499106f5e1e1d68a0b5ddeedf403
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1569
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
| |
Change-Id: I47a8ad7914c6833c476a7944be5d352f45467f3a
RTC: 47725
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1646
Tested-by: Jenkins Server
Reviewed-by: Mark W. Wenning <wenning@us.ibm.com>
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
| |
* Choose thread with the lowest PIR as the last to enter payload.
* Use HRMOR update process from Murano Book IV.
RTC: 43166
Change-Id: I629f4a55cba1967a13c31a16095697b7142ca407
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1529
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Due to the LPCR values, nap can already be exited by an
interrupt or decrementer event. Remove EE in the MSR so
that we are guarenteed that we fully enter nap even if
there is a interrupt or decrementer pending.
Change-Id: If70f82ea7c05576c1dd97de9e2a1d930c36ba46f
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1515
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
| |
RTC: 44730
Change-Id: Ifaeecc659e1bfd8ded4744dc591fc993471519ba
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1471
Tested-by: Jenkins Server
Reviewed-by: Mark W. Wenning <wenning@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
| |
Change-Id: Ifd611129c2d7173b5e0dec36c870e06a4d851009
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1384
Tested-by: Jenkins Server
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
| |
RTC: 43738
Change-Id: I91c2bfe57bba04a02dd5169542de8e76e1654ae8
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1387
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Task 44887
Change-Id: If87b6e80b974bb4cbff13844d8a3f055a17282d2
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1378
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: Mark W. Wenning <wenning@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
| |
RTC: 37009
Change-Id: I56669805c86d9659a20ad7c26e5e9860c7a248c7
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1087
Tested-by: Jenkins Server
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Allow page allocation system call to force coalesce if a
contiguous block is unavailable. [long-term enhancement]
* Workaround lack of large contiguous memory for PageTable
test-cases, which require 256K, by allocating a VMM block.
This should be removed when story 43401 is implemented.
[short-term workaround]
Change-Id: Idddb30eaa3aeac52d56b82a70355095f31d4a0cd
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1369
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: Douglas R. Gilbert <dgilbert@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Debug tool for PageManager.
* Support PageMgr allocations of non-2^k size.
* Switch page-allocation to always be in kernel-mode.
While investigating issue 44511, I noticed two problesm with the
memory page allocator (PageManager). First, the allocator did
not support allocations of pages which were not a power of 2,
which would result in pages appearing to "leak". Second, in
situations where a large allocation was requested and there was
not a large chunk available, the allocation would enter a
live-lock condition where coalescing would never occur.
Switched the PageManager so that all allocations happen in
kernel space. This allows us to force memory-release operations
on the syscall path when we are out of memory and also put in
place a task_yield call which will allow coalescing to eventually
occur. Issue 44523 is suppose to fully resolve any of these
live-lock paths.
RTC: 44511
Change-Id: Ifefd5d0996ee6914e291c862fac0c7b76980717f
Reviewed-on: http://gfw160.austin.ibm.com:8080/gerrit/1330
Tested-by: Jenkins Server
Reviewed-by: Daniel M. Crowell <dcrowell@us.ibm.com>
Reviewed-by: A. Patrick Williams III <iawillia@us.ibm.com>
|