laser-lovers@uw-beaver (10/15/85)
From: Allan Weber <WEBER@USC-ECLC.arpa> We have had an Imagen 8/300 with 1.5Mb of memory (two 768kb memory boards) connected to a Vax-Unix system since about March of this year and recently had an educational and odd experience with it. The symptoms of the problem was that about once each month it would quietly die while printing a large job. Usually with no warning messages on the console, it would just stop working until somebody noticed the lack of activity and re-booted it. It would only die if the number of pages processed exceeded the number of pages printed by about 40 or more. This would happen on a troff file being printed with page reversal on, and also with a large TeX file if the processing was going a lot faster than the printing. It looked like the sort of thing that would happen if the upper half of the memory was not working and the processor didn't know about it. However, each time the processor was booted, it passed the self test and announced the presence of both 768kb memory boards so I assumed that the memory was working and the problem was in the software. I finally called Imagen (after the warrently had expired) and told them about the problem. They said it sounded like a hardware problem and connected me to somebody in the hardware department. He suggested swapping the memory boards, making the upper 768kb become the lower memory and vice-versa. Upon doing this, the 8/300 would still pass the self test but then stop dead prior to printing out them message about the memory present. Swapping the boards back to the original configuration got the machine running again, still insisting that both 768kb boards were working. Imagen's hardware person said this proved that the upper memory board was bad. We are now getting a replacement memory board from Imagen for $400. This Monday I was wandering around the exhibit hall at the SUN User Group meeting in Los Angeles and starting telling somebody in the Imagen booth about this problem. I asked why the 8/300 was able to detect the presence of the board but not detect that it was bad. He told me that it takes too long to run memory diagnostics in 1.5Mb of memory so the self test does not include a memory test. He implied that there was no real need for memory diagnostics since my large print jobs apparently did a good job of finding the bugs. Even though the actions of our 8/300 seem to bear this out I find it hard to believe that the self test doesn't do some sort of memory test. I suppose that running a real, full scale, diagnostic test that pounds the bits apart on that much memory can take a long time but I feel like the problem on our 8/300 could be found by a test of every 1k'th byte or something like that. An alternative would be to supply a diagnostic program on the floppy that a user could run if suspicious of the memory. I find it hard to blame Imagen for most of this situation since I should have called them and tracked the problem down the first time it happened, while the machine was still under warrenty. They were very helpful when I did get around to contacting them. However, I have learned that just because my 8/300 says that it found all the memory that I know is in the box, doesn't mean that it's working. Allan Weber Weber@USC-ECLC -------
laser-lovers@cca.UUCP (10/15/85)
From: Allan Weber <WEBER@USC-ECLC.ARPA> We have had an Imagen 8/300 with 1.5Mb of memory (two 768kb memory boards) connected to a Vax-Unix system since about March of this year and recently had an educational and odd experience with it. The symptoms of the problem was that about once each month it would quietly die while printing a large job. Usually with no warning messages on the console, it would just stop working until somebody noticed the lack of activity and re-booted it. It would only die if the number of pages processed exceeded the number of pages printed by about 40 or more. This would happen on a troff file being printed with page reversal on, and also with a large TeX file if the processing was going a lot faster than the printing. It looked like the sort of thing that would happen if the upper half of the memory was not working and the processor didn't know about it. However, each time the processor was booted, it passed the self test and announced the presence of both 768kb memory boards so I assumed that the memory was working and the problem was in the software. I finally called Imagen (after the warrently had expired) and told them about the problem. They said it sounded like a hardware problem and connected me to somebody in the hardware department. He suggested swapping the memory boards, making the upper 768kb become the lower memory and vice-versa. Upon doing this, the 8/300 would still pass the self test but then stop dead prior to printing out them message about the memory present. Swapping the boards back to the original configuration got the machine running again, still insisting that both 768kb boards were working. Imagen's hardware person said this proved that the upper memory board was bad. We are now getting a replacement memory board from Imagen for $400. This Monday I was wandering around the exhibit hall at the SUN User Group meeting in Los Angeles and starting telling somebody in the Imagen booth about this problem. I asked why the 8/300 was able to detect the presence of the board but not detect that it was bad. He told me that it takes too long to run memory diagnostics in 1.5Mb of memory so the self test does not include a memory test. He implied that there was no real need for memory diagnostics since my large print jobs apparently did a good job of finding the bugs. Even though the actions of our 8/300 seem to bear this out I find it hard to believe that the self test doesn't do some sort of memory test. I suppose that running a real, full scale, diagnostic test that pounds the bits apart on that much memory can take a long time but I feel like the problem on our 8/300 could be found by a test of every 1k'th byte or something like that. An alternative would be to supply a diagnostic program on the floppy that a user could run if suspicious of the memory. I find it hard to blame Imagen for most of this situation since I should have called them and tracked the problem down the first time it happened, while the machine was still under warrenty. They were very helpful when I did get around to contacting them. However, I have learned that just because my 8/300 says that it found all the memory that I know is in the box, doesn't mean that it's working. Allan Weber Weber@USC-ECLC -------