tony@xios.UUCP (Keeper Of News) (06/26/86)
We have a 3B2/300 and a 3B2/400. Until recently they were running SV Release 2.0. We got a Release 2.1 source distribution, and brought it up on these machines. Release 2.1 has demand paging, which we need to get our software up and running on this machine, since it wouldn't fit with the 500k limit on text size in Release 2.0. Unfortunately, the Cartridge tape subsystem comes from a third party, and we didn't get any binaries for it, and they won't release source. This means that we had to use the binaries from Release 2.1 in our 2.2 kernel. Not surprisingly, this has not been terribly successful. Now, I would expect any commands to die immediately when attempting to run them, but the actual problems have been stranger. (Note that we are using the old DRIVER with the new kernel). Suspecting that the problem is with the old binaries, we have tried to get a binary distribution of the cartridge tape system from ATT in Canada. The have refused to send us one (though not in so many words). We were hoping that some kind soul in the US would be willing to give/sell us a copy of it. What follows is a more detailed description of our problems, in case someone knows of something else which could be causing it. Our immediate need is to be able to back up our filesystems so we can repartition the disks so that we have enough room on root and usr to do some work. One small problem with Release 2.1 is that all the binariers are 10-20% larger, which eats most of the free space in the filesystems. (I have no desire to back up all that junk with floppies, though I may have to as a last resort). Specificly, on the 300, when we try to backup a filesystem (using ctccpio), there is a good chance that the system will crash with a PANIC: SYSTEM PARITY ERROR INTERRUPT or more rarely KERNEL MMU FAULT (F_STDLEN) shortly after the operation is complete. I have only managed to get it to complete the operation once, and have not tried to read the tape back. I suspect I would have the same problem as with the 400 if I were to try. I also tried using plain cpio, but I was not able to read back the tape that was generated. On the 400, we can create a cpio tape with ctccpio, but when we try to read the tape back, the machine dies with: PANIC: KERNEL DATA ALIGNMENT ERROR and once it got the machine into a state where any system call would generate a: NOTICE: growreg/ptalloc - Insufficient memory to allocate 1 page - system call failed and eventually an MMU FAULT as with the 300. -- ------------------------------------------------------------------------------- Tony Lill Keeper of News @ Xios Systems Corporation 1600 Carling Avenue, Suite 150, Ottawa, Ontario, Canada, K1Z 8R8 (613) 725-5411 xios!tony ------------------------------------------------------------------------------- Not the edge of the world, but we can see it from here.
paul@unisoft.UUCP (Paul Campbell) (07/07/86)
<oog> It sounds like you need new drivers. The paging kernel allows drivers to do transfers to processes that are not contiguous (in most swapping kernels processes are loaded in contiguous blocks). When you do raw IO one of three things must happen 1) The buffer is contiguous in core (ie the process is contiguous, or special code to make bits of processes contiguous prior to the start of the IO) 2) Special hardware (like the Unibus map on a vax or 11), these are only just starting to turn up in 'super-micro' size machines. Most of the new DMA chips (including the AT&T DMA chip .... an very well thought out piece of work) support some form of scatter/gather operation .... but not the 3b2/300/400. 3) Chop the IO up into page size pieces, buffering any bits that cross page boundarys (what V.2.1 does on the 3b2). This last requires drivers to do some different (minorly different) things and may result in the sort of crashes you are seeing. Running a binary should NOT be able to cause a kernel to crash ..... unless the binary is working with a bad piece of kernel code. Paul Campbell ..!ucbvax!unisoft!paul