cspencer@bbncc5.UUCP (Clifford Spencer) (10/11/85)
In 4.2 and ULTRIX hp.c(hpecc) I see the following happening under the ECC case: npf--; /* because block in error is previous block */ * mpte = mbp->mba_map[npf+btop(byte)]; * (correct error here) * npf++; Why the fiddling with npf? What if npf is initially zero and byte < 512? If the error occurs in the first page of a transfer, isn't npf going to go negative and we will reference mba_map[-1] ? Can someone explain this? -cliff -- cliff spencer {harvard, ihnp4, decvax}!bbnccv!cspencer cspencer@bbncc5
dave@onfcanim.UUCP (Dave Martindale) (10/13/85)
In article <672@bbncc5.UUCP> cspencer@bbncc5.UUCP (Clifford Spencer) writes: >In 4.2 and ULTRIX hp.c(hpecc) I see the following happening under >the ECC case: > > npf--; /* because block in error is previous block */ > * > mpte = mbp->mba_map[npf+btop(byte)]; > * (correct error here) > * > npf++; npf is calculated as the number of sectors of data that have already been transferred. In the case of a BSE (bad sector) error, this does not include the block with the problem since the transfer is aborted before moving any data. But for an ECC error, the data in the block *has* been transferred to memory, and the controller's ECC registers tell you how to correct that last sector of data. Thus "npf" is really pointing to the *following* sector, and is decremented to point to the sector with the error. >Why the fiddling with npf? What if npf is initially zero and byte < 512? >If the error occurs in the first page of a transfer, isn't npf going to >go negative and we will reference mba_map[-1] ? Can someone explain this? In the case of an ECC error, npf cannot be zero since at least one sector has already been transferred into memory. Dave Martindale