/* (5.35)
*
* This file is automatically maintained by srccommit, do not edit manually.
* Last processed by srccommit version: 1.1.
*
*/
#define Module_MajorVersion_CMHG 5.35
#define Module_MinorVersion_CMHG 4.79.2.98.2.31
#define Module_Date_CMHG 02 Sep 2010
#define Module_MajorVersion "5.35"
#define Module_Version 535
#define Module_MinorVersion "4.79.2.98.2.31"
#define Module_Date "02 Sep 2010"
#define Module_ApplicationDate "02-Sep-10"
#define Module_ComponentName "Kernel"
#define Module_ComponentPath "castle/RiscOS/Sources/Kernel"
#define Module_FullVersion "5.35 (4.79.2.98.2.31)"
#define Module_HelpVersion "5.35 (02 Sep 2010) 4.79.2.98.2.31"
#define Module_LibraryVersionInfo "5:35"-
Jeffrey Lee authored
Detail: s/VMSAv6 - The code in DAbPreVeneer that checks for aborting MVA-based cache/TLB ops is now re-entrant. This is to cope with the "strange but true" case where a data abort was being triggered by a load/store instruction that itself was in an unmapped page. Admin: Tested on rev C2 beagleboard. Fixes issue with StrongED crashing on load (see http://www.riscosopen.org/forum/forums/5/topics/453) Still need to work out why CPU was able to execute code from the unmapped page without triggering a prefetch abort (stale cache entries?) Version 5.35, 4.79.2.98.2.31. Tagged as 'Kernel-5_35-4_79_2_98_2_31'
9aa05feb