Hi Johnson, thanks for posting the error message!

Analysis: LBAcache *newbin* in binsel2.asm seems to suggest allocating cache
slots beyond the end of the cache sometimes (you used a 2 MB cache, I guess),
you got attempts to copy data TO cache 16, 48, 80 and 176 sectors after the
actual end of the cache (10, 30, 50 and b0 hex), each for a whole element of
16 sectors. Luckily you only got DOS->XMS errors and no DOS<-XMS errors, so
LBAcache never tries to read "cached" data from the void.

I think I can fix this bug - which got introduced in the "more speed" update
earlier this month (6/2004) - by letting newbin always do a fresh calculation
of the "search start position of 16(element)-way associative cache allocation".
The bug seems to be that newbin uses cached results from findbin, but findbin
would NOT update this variable if the relevant bin was found using the 256+1
entry memoization table. The STRANGE thing is that "if findbin DID find a bin,
then newbin just fills that bin MORE - it should NOT allocate a completely
fresh bin then".

I have to look closer at binsel2.asm, maybe the bug is something else. Anyway,
thanks for providing the error log.

Oh, wait...
> DOS<-XMS.1057
In one of the many accesses, LBAcache failed to return data when Cubic
Player tried to read from disk. The error was not reported to Cubic Player,
only on screen. This only happened in the "disk read" which directly read
back data which was supposed to be written to disk and cache just a moment
before (still in the 1 "most recent" element of the memoization...). LBAcache
has failed to copy the data to cache, so reading back the data must have
failed, too. I think this is because in *findbin* the other 256 elements of
the memoization table are overflow protected - not sure if the search algorithm
for the rest of the cache can get affected by the new bug, BUT 256 elements
are 2 MB and you only tested with a 2 MB cache - so only (much) BIGGER caches
could get overflows in findbin outside the memoization trace, and only for
access patterns where the memoization strategy is not fully successful.

Thanks again for the log...


This SF.Net email is sponsored by The 2004 JavaOne(SM) Conference
Learn from the experts at JavaOne(SM), Sun's Worldwide Java Developer
Conference, June 28 - July 1 at the Moscone Center in San Francisco, CA
REGISTER AND SAVE! http://java.sun.com/javaone/sf Priority Code NWMGYKND
Freedos-user mailing list

Reply via email to