Path: utzoo!news-server.csri.toronto.edu!rutgers!dimacs.rutgers.edu!mips!daver!bungi.com!news From: jvh@galactus.hut.fi (Johannes Helander) Newsgroups: comp.sys.nsc.32k Subject: Re: Is the bug with operands crossing page boundaries still in 32532 ? Message-ID: <9103130449.AA03880@galactus.hut.fi> Date: 13 Mar 91 04:49:59 GMT Sender: news@daver.bungi.com Reply-To: jvh@sauna.hut.fi Organization: Helsinki University of Technology, CS Lab. Lines: 38 Approved: news@daver.bungi.com Jonathan Ryshpan writes: > As I remember it, the problem was that instructions line NEG produced a > read cycle followed by a write cycle instead of a read-modify-write > cycle. This broke copy on write (for forks), for reasons I don't > remember. I don't know whether the ns532 has fixed this or not. Dave > Rand?? [I think I mentioned this already some time ago, so sorry for boring you] At least when a sbiti (interlocked set bit) instruction page faults will the msr contain an incorrect value. The only way to find out that the trap was in fact caused by a read-modify-write cycle is to look at the instruction itself (check if it is sbiti). This can of course be optimized by saving the address and by looking at the instruction only when the previous address was the same. Anyway still ugly. Are there other known situations when this may happen? It is of no help to look at the instruction if not knowing what to look at. What is meant by 'instructions line NEG'? Do I smell trouble? The problem with copy on write here is that no unnecessary write access will be given. If the page fault handler is presented with a read fault, it will just upgrade the access to read. Then the instruction will again read fault, it will gain read access, fault,... ad infinitum. It is thus necessary to correctly recognize write faults even when the harware is lying about them. To recognize such a situation the situation must be known. Some check could of course be added to panic the operating system (and report that it found a hardware bug) or something similar if the same instruction causes a read trap over and over again. Are there other known bugs (except movus/movsu using both ptbs even in single address space mode)? Does anyone have a buglist? Johannes