ggs@ulysses.UUCP (07/20/83)
I have seen several panics caused by hard read errors when reading from a TU78. This happened under 4.1c and 4.1. There seems to be a basic problem with the mba interface when using the TU78 device driver. According to my TM78 user guide, the TM78 will sometimes present a "read opposite" status, which means that I should re-try the read from the other direction. The manual says that the correct response to that error is: 1. Use Record Count to dequeue records correctly transferred, then set Record Count to 0. 2. Read the guesstimate Byte Count from the controller and use that count to compute the address of the other end of the buffer. Store this revised address in the mba Virtual Address Register. 3. Issue READ FWD or READ REV depending on the sense of the command that started everything before the error was reported. After several hours of wading through the ($%^^@#$%$% undocumented) mt.c and mba.c code, I can't find anything in mba.c that computes the address of the end of the buffer if the command is READ REV. I also can't find anything in mt.c that determines whether the "read opposite" status means READ FWD or READ REV. This may explain some problems that I have observed. When I allocate an input buffer near the end of a page in the static area and then try to read a bad record into that buffer, one of the following will happen: 1. If I am lucky, the bytes in front of the first byte in the buffer will be filled with data from the bad record. This trash data will begin on the first byte of the page that contains the buffer. 2. If I am unlucky, the kernel will panic with "mba: zero entry" when it tries to map a page onto the mba and finds an invalid value in the page table entry. The first failure is consistent with the model that the address of the start of the buffer is being interpreted as the address of the end of the buffer. The second failure doesn't make any sense to me, but who knows what happens when you try to read data into addresses not mapped by the mba. Does anyone out there have a 'real' TU78 driver? Has this been fixed in 4.2? (Apocryphal (mis)quote from someone in authority at DEC: "programmers who don't comment their code should be shot! If that is inconvenient, they should forced to do it over the right way!"). -- Griff Smith Bell Labs, Murray Hill Phone: (201) 582-7736 Internet: ggs@ulysses.uucp UUCP: ulysses!ggs