Jürgen, Fredrik -- > > Would you be able to explain the notes > > > > /* In an error exception handler the user space could be uncached. */ > > > > in the patch ported from v2.6 below? > > The tx79architecture.pdf says: > 2.4 kuseg becomes an uncached area when an error exception (Status.ERL = 1) occurs (FLX04) > 2.4.1 Phenomenon > There are cases in which kuseg (0x0000_0000 – 0x7FFF_FFFF) becomes uncached in an error exception handler (Status.ERL==1) and data consistency with cached area (kseg, ksseg, kseg0) is lost. > 2.4.2 Corrective measures > In an error exception handler (Status.ERL==1), when accessing kuseg (0x0000_0000 – 0x7FFF_FFFF), access it after guarding using SYNC.L as follows: > SYNC.L > SW ku seg This change makes no sense to me anyway I am afraid. At the error level (Status.ERL=1) the user segment becomes unmapped and therefore all KUSEG addresses become physical addresses. Which means that if any of this code you have patched is called to access user pages, then you have a bigger problem than just the cache going out of sync. The only reason to access KUSEG at the error level is to save/restore register state to/from a dedicated RAM area offset from $zero so that execution is restartable. Unlike at the exception level you cannot use $k0 and $k1 as temporaries, because an error exception can happen any time including in particular while $k0 and $k1 are in active use at the exception level, so clobbering them would make the system non-restartable (of course receiving an error exception may mean that anyway). Code to write/read that dedicated area should be purpose-crafted and the area won't be accessed at any other time, so the issue of being cache coherent or not does not apply as the area will never be accessed with caching operations. I can see the R5900 has additional classes of error exceptions defined, such as debug and performance counter exceptions, which are not related to hardware faults and can happen in regular execution in response to certain conditions requested. If you want to handle these implementation specific extensions and consequently serve these exceptions, then please take care of all the requirements as code to support them is added. Though as I wrote above it does not look to me like anything specific will be needed -- the handler at entry will save the state necessary for restartability to a dedicated RAM area first and then to the kernel stack, switch the error level off, do the necessary processing, and then reverse the steps before resuming execution interrupted. Maciej
