mahesh@caradhras.cc.nd.edu (Mahesh "BigMan" Subramanya) (03/28/91)
I really don;t know why this is happening, but it is definitely starting to irritate me. THE PROBLEM -> All the windows on my workspace randomly get "spotted", i.e., little light gray dots show up, seemingly at random, on any window that I open, Lately, the density has been increasing. I replace the entire code under /usr/lib/NextStep from the OD, but the spottiness did not abate. The only other data point that I have is, when I finished level 12 under BlastApp, there was a BOOM, and the spots began. Coincidence? or intentional (i think not). has anyone seen this before? Ali, did you intend this? 'Elp!!!! I don;t want to reload the OS on me cube. -- **************************M-V-S?? EX-TER-MI-NATE!!!********************* Mahesh Subramanya INTERNET: mahesh@darwin.cc.nd.edu Senior Analyst Office of University Computing University of Notre Dame Voice: (219) 239-5600 x6421 Notre Dame, IN 46556 ************************************************************************
simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) (04/03/91)
Sounds like you have memory problems.
bennett@mp.cs.niu.edu (Scott Bennett) (04/04/91)
In article <5596@media-lab.MEDIA.MIT.EDU> simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) writes: >Sounds like you have memory problems. And further, if you get no error messages when it happens, I'd lay some cash down that you have non-parity memory. And if that is indeed the case, just how intact would be willing to bet your software and data are by now? To limit the damage, I would not boot the system again until it has been fixed, if I were you. Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
sritchie@cs.ubc.ca (Stuart Ritchie) (04/05/91)
In article <1991Apr3.230504.27819@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >In article <5596@media-lab.MEDIA.MIT.EDU> simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) writes: >>Sounds like you have memory problems. > > And further, if you get no error messages when it happens, I'd lay >some cash down that you have non-parity memory. And if that is indeed >the case, just how intact would be willing to bet your software and >data are by now? To limit the damage, I would not boot the system again >until it has been fixed, if I were you. > > > Scott Bennett, Comm. ASMELG, CFIAG Hey guys, if the problem was actually bad DRAM, with visible spotting on the screen, do you think that the system would even run? I mean, it's kinda like executing random code hmm? If software still runs, it sounds to me like the VRAM is shot. After all, it is the screen that's being affected. But I'm no expert, only guessing like everyone else. --- As for the latest threads about "NeXT should produce a cheaper machine with slower CPU" I do not agree with at all. Don't forget how badly the 030 cube was criticized for poor perceived performance. The last thing NeXT needs is another target for cheap shots from other vendors. The RISC vs CISC debate is moot. I think it would be a really bad move for NeXT to abandon the 680x0 series as their general purpose application CPU, especially after only 2 years! Notice that I say _general purpose_. I would certainly welcome multiprocessor support based on other chips. The DSP, i860 and C-Cube are fine examples. Personally, I would like to see NeXT offload networking support to a dedicated CPU. Protocol performance inside the Unix kernel is relatively poor (that's an understatement) compared to more special purpose implementations. Just like their special purpose Mach and DPS implementation on the i860, one could see a lightweight Mach and x-kernel running TCP/IP on an 88000 based board. Hell, even a 68020 would probably be better than sucking cycles from the 040 at each Ethernet interrupt. Of course, you must add the possibility for extensibility. Users and third parties must be able to run their own protocol suites. But those are details that o/s types like me love to figure out. If NeXT did this, I would be really impressed. Finally our machines could reach Ethernet speeds! Out-on-limb-statement: Dedicated multiprocessors are the way to go. Of course, a few 040's for general application use would also help :-) In fact, writing the o/s for a dedicated multiprocessor FDDI board is my thesis topic. If anyone experienced with hardware and software issues related to dedicated multiprocessing would like to comment, please do! I would love to hear how it _really_ works. Later dudes! ...Stuart <sritchie@cs.ubc.ca> Wot's... uh the deal?
louie@sayshell.umd.edu (Louis A. Mamakos) (04/06/91)
In article <1991Apr5.075135.23325@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes: >Personally, I would like to see NeXT offload networking support >to a dedicated CPU. Protocol performance inside the Unix kernel >is relatively poor (that's an understatement) compared to more >special purpose implementations. I disagree with this comment. Can you cite any references or examples to support this? I have not found the performance of UNIX kernel based TCP/IP to be an issue. >Just like their special purpose Mach and DPS implementation on >the i860, one could see a lightweight Mach and x-kernel running >TCP/IP on an 88000 based board. Hell, even a 68020 would probably >be better than sucking cycles from the 040 at each Ethernet >interrupt. Of course, then you have to worry about how to move the data to and from the special purpose "network" processor to where the UNIX kernel can get at it, and shove it into and out of socket buffers, etc. Look real hard at what tcp_input() does in the most common case for bulk data transfers; its not that many instructions. The great pile 'o code that's in there is for the (relatively) unusual case where packets get dropped, retransmissions, out of order segments, etc. If your network traffic begins to operate in that regime much of the time, you can probably forget about performance and worry about what's wrong with your network. >If NeXT did this, I would be really impressed. Finally our machines >could reach Ethernet speeds! >Out-on-limb-statement: Dedicated multiprocessors are the way to go. >Of course, a few 040's for general application use would also help :-) I agree that having multiprocessors would be a good thing; I just don't think that dedicating one for network stuff (or any other thing, for that matter) will be any better than what you have right now. If you're interested in raw network performance, wouldn't you rather have a 68040 doing the protocol processing (which really isn't that intensive in most cases) rather than having a slower processor do part of the work, and then having to give it to the faster processor? Witness the utter failure of "intelligent" ethernet cards in the PC marketplace as compared to "dumb" ethernet cards. The performance win just isn't there. louie
melling@cs.psu.edu (Michael D Mellinger) (04/06/91)
In article <1991Apr5.075135.23325@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes:
As for the latest threads about "NeXT should produce a cheaper
machine with slower CPU" I do not agree with at all. Don't
forget how badly the 030 cube was criticized for poor perceived
performance. The last thing NeXT needs is another target for
cheap shots from other vendors.
A NeXT with an educational discount of $2500 would definitely sell a
lot better than the current machine(not that it isn't selling well),
but NeXT would still have to deal with "but it doesn't have color."
The RISC vs CISC debate is moot. I think it would be a really
bad move for NeXT to abandon the 680x0 series as their
general purpose application CPU, especially after only 2 years!
HP will sell you a machine with a SPECmark of 54(57?) for $12,000.
Next year, the other workstation vendors will match that. NeXT will
get left behind if they don't move to RISC. As a friend of mine likes
to point out, NeXT has to be better than everyone else. People will
buy from the competition just because they have always bought from the
competition. Take Sun and Apple as to examples.
Quintessential example: I B M
Notice that I say _general purpose_. I would certainly welcome
multiprocessor support based on other chips. The DSP, i860 and
C-Cube are fine examples.
Out-on-limb-statement: Dedicated multiprocessors are the way to go.
Of course, a few 040's for general application use would also help :-)
Or one MIPS R4000.
-Mikebennett@mp.cs.niu.edu (Scott Bennett) (04/06/91)
In article <1991Apr5.075135.23325@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes: >In article <1991Apr3.230504.27819@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >>In article <5596@media-lab.MEDIA.MIT.EDU> simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) writes: >>>Sounds like you have memory problems. >> >> And further, if you get no error messages when it happens, I'd lay >>some cash down that you have non-parity memory. And if that is indeed >> [text deleted --SJB] > >If software still runs, it sounds to me like the VRAM is shot. >After all, it is the screen that's being affected. But I'm no >expert, only guessing like everyone else. Good point. I wasn't thinking. So, the VRAM is non-parity crap, too, huh? What a bummer. Is the VRAM on a 68040 board like that, too? I hope not because I just bought the upgrade kit a week ago (it's not installed yet) and it will definitely ruin my day to discover that I'm still going to have a toy computer instead of a real, production one. > >--- > [more deleted --SJB] > >Later dudes! >...Stuart <sritchie@cs.ubc.ca> Wot's... uh the deal? Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
tyc@cbnewse.att.com (felix.a.lugo) (04/07/91)
In article <1991Apr6.043551.29580@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: | In article <1991Apr5.075135.23325@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes: | >In article <1991Apr3.230504.27819@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: | >>In article <5596@media-lab.MEDIA.MIT.EDU> simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) writes: | >If software still runs, it sounds to me like the VRAM is shot. | >After all, it is the screen that's being affected. But I'm no | >expert, only guessing like everyone else. | | Good point. I wasn't thinking. So, the VRAM is non-parity crap, | too, huh? What a bummer. Is the VRAM on a 68040 board like that, too? | I hope not because I just bought the upgrade kit a week ago (it's not | installed yet) and it will definitely ruin my day to discover that I'm | still going to have a toy computer instead of a real, production one. | > What a load of s..t! Do you really believe that you have a toy computer just because it doesn't have parity VRAM? How many parity erros have you seen recently in "production" systems that cause all your work to get lost when the system decided that it could no longer continue? Parity RAM does nothing to a system unless it contains some ECC logic to correct the problem. Parity RAM only informs the system that some memory has gone bad. Would you like your NeXT to shutdown because you have a fault in you VRAM? I certainly would not!!!!! | | Scott Bennett, Comm. ASMELG, CFIAG | Systems Programming | Northern Illinois University | DeKalb, Illinois 60115 /* ** ============================================================================ ** ** Felix A. Lugo ** ** E-Mail (including NeXTMail): ** Felix_A_Lugo@ATT.COM ** att!ihcoco!coco ** ** ============================================================================ */
zazula@uazhe0.physics.arizona.edu (RALPH ZAZULA) (04/07/91)
In article <1991Apr6.205555.21974@cbnewse.att.com>, tyc@cbnewse.att.com (felix.a.lugo) writes... >In article <1991Apr6.043551.29580@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >| In article <1991Apr5.075135.23325@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes: >| >In article <1991Apr3.230504.27819@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >| >>In article <5596@media-lab.MEDIA.MIT.EDU> simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) writes: >| >If software still runs, it sounds to me like the VRAM is shot. >| >After all, it is the screen that's being affected. But I'm no >| >expert, only guessing like everyone else. >| >| Good point. I wasn't thinking. So, the VRAM is non-parity crap, >| too, huh? What a bummer. Is the VRAM on a 68040 board like that, too? >| I hope not because I just bought the upgrade kit a week ago (it's not >| installed yet) and it will definitely ruin my day to discover that I'm >| still going to have a toy computer instead of a real, production one. >| > > What a load of s..t! Do you really believe that you have a toy > computer just because it doesn't have parity VRAM? How many parity > erros have you seen recently in "production" systems that cause all > your work to get lost when the system decided that it could no longer > continue? Parity RAM does nothing to a system unless it contains some > ECC logic to correct the problem. Parity RAM only informs the system > that some memory has gone bad. Would you like your NeXT to shutdown > because you have a fault in you VRAM? I certainly would not!!!!! Hmm... What happens when the parity bit goes in your parity memory? With the odds being 1-in-9 (if you really believe that bits bite the dust quite often) I can't see parity memory as something to put ones mind at ease... I also agree that the video memory isn't as critical as program/data RAM. An acceptable thing would be for the system to report bad VRAM at power-up. As for program/data RAM, there are a lot of 8-bit MAC's out there being used for many things. I don't see a lot of people complaining about loss of data or poor results (eg. FermiLab, Argonne...). I don't know what one expects will happen to only 8-out-of-9 bits leaving parity in tact. If you are really parinoid about memory going bad, then you should be looking into more fault-tolerant systems. I've also been somewhat amused to see people talking about "random cosmics" trashing bits... I'd be more afraid of "random criminals" or "random power spikes" etc... Note, however, that I haven't done the calculation for the cross-section of a cosmic (say, muon) with the 12Meg in my cube. I guess I'd need to know the geometry of the RAM and how much added charge is required to change a bit... If you disagree with any of this, it may not be what I typed... Could have been a 1GeV u kicking through this document... :-) Ralph > >| >| Scott Bennett, Comm. ASMELG, CFIAG >| Systems Programming >| Northern Illinois University >| DeKalb, Illinois 60115 > >/* >** ============================================================================ >** >** Felix A. Lugo >** >** E-Mail (including NeXTMail): >** Felix_A_Lugo@ATT.COM >** att!ihcoco!coco >** >** ============================================================================ >*/ |----------------------------------------------------------------------| | Ralph Zazula "Computer Addict!" | | University of Arizona --- Department of Physics | | UAZHEP::ZAZULA (DecNet/HEPNet) | | zazula@uazhe0.physics.arizona.edu (Internet) | |----------------------------------------------------------------------| | "You can twist perceptions, reality won't budge." - Neil Peart | |----------------------------------------------------------------------|
bennett@mp.cs.niu.edu (Scott Bennett) (04/08/91)
In article <1991Apr6.205555.21974@cbnewse.att.com> tyc@cbnewse.att.com (felix.a.lugo) writes: >In article <1991Apr6.043551.29580@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >| In article <1991Apr5.075135.23325@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes: >| >In article <1991Apr3.230504.27819@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >| >>In article <5596@media-lab.MEDIA.MIT.EDU> simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) writes: >| >If software still runs, it sounds to me like the VRAM is shot. >| > [text deleted --SJB] >| > > What a load of s..t! Do you really believe that you have a toy > computer just because it doesn't have parity VRAM? How many parity Well, I supposed having the *displayed image* damaged is not as bad as having data in main memory damaged, but it *would* be irritating, especially if it made it difficult to communicate with the software. > erros have you seen recently in "production" systems that cause all > your work to get lost when the system decided that it could no longer > continue? Parity RAM does nothing to a system unless it contains some > ECC logic to correct the problem. Parity RAM only informs the system (one more time, sigh) First, yes, I see single-bit errors frequently enough on equipment that is capable of detecting them. However, even systems that have parity, but not ECC, memory are able to make use of the information. For example, a data page that has not been modified since its last pageout or a text page can be refreshed from a file or a paging area. In the case of a dirty data page, the kernel/supervisor can terminate the affected program. If the damage is in a kernel page, then the choice of solutions can be a bit more complex, but more times than not a well written system can make repairs and continue. Repairs should include, of course, marking the affected block of memory as being unusable, so that it can't cause any more problems as long as the system stays up and running. > that some memory has gone bad. Would you like your NeXT to shutdown > because you have a fault in you VRAM? I certainly would not!!!!! Of course not, but it would be nice to have the errors logged. Logging the errors makes it easier to know what needs to be fixed. > >| >/* >** ============================================================================ >** >** Felix A. Lugo >** >** E-Mail (including NeXTMail): >** Felix_A_Lugo@ATT.COM >** att!ihcoco!coco >** >** ============================================================================ >*/ Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************
bennett@mp.cs.niu.edu (Scott Bennett) (04/08/91)
In article <1991Apr6.152816.502@arizona.edu> zazula@uazhe0.physics.arizona.edu writes: >In article <1991Apr6.205555.21974@cbnewse.att.com>, tyc@cbnewse.att.com (felix.a.lugo) writes... >>In article <1991Apr6.043551.29580@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >>| In article <1991Apr5.075135.23325@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes: >>| >In article <1991Apr3.230504.27819@mp.cs.niu.edu> bennett@mp.cs.niu.edu (Scott Bennett) writes: >>| >>In article <5596@media-lab.MEDIA.MIT.EDU> simsong@daily-bugle.media.mit.edu (Simson L. Garfinkel) writes: >>| >If software still runs, it sounds to me like the VRAM is shot. >>| > [text deleted --SJB] > >Hmm... What happens when the parity bit goes in your parity memory? The same thing as with any of the other bits. You get a single-bit error. >With the odds being 1-in-9 (if you really believe that bits bite the dust >quite often) I can't see parity memory as something to put ones mind at >ease... I also agree that the video memory isn't as critical as program/data Most parity, non-ECC memory is not up to detecting errors of two or more bits in a byte. However, most errors are single-bit errors because only one chip is going bad, and memory that's going bad will be likely to have single-bit errors before it starts getting multiple-bit errors. Then you can get it replaced. >RAM. An acceptable thing would be for the system to report bad VRAM at >power-up. As for program/data RAM, there are a lot of 8-bit MAC's out there I disagree. As you know by now, many errors are intermittent, especially when they first crop up. A chip going bad might not make the error, for example, when you first turn the machine on and the chip is still cool. Give it ten or fifteen minutes and it may have problems. >being used for many things. I don't see a lot of people complaining about >loss of data or poor results (eg. FermiLab, Argonne...). I don't know what Well, maybe for word processing it isn't that important. If they're using it for anything more sensitive, well, ignorance is bliss, at least for a while... Besides, if the hardware can't tell them, how would they even know? >one expects will happen to only 8-out-of-9 bits leaving parity in tact. Well, that would be a multiple-bit (i.e. multiple chip) error. Not much you can do about that, beyond maybe detecting a double-bit error, but that does take considerably more costly equipment. >If you are really parinoid about memory going bad, then you should be looking >into more fault-tolerant systems. Like pee cee clones, maybe? As overrated as they are in most other ways, pee cees and their clones can usually at least tell you when they've f****d up. > > [text deleted --SJB] > >If you disagree with any of this, it may not be what I typed... Could >have been a 1GeV u kicking through this document... :-) > >:-) > >Ralph >> > > |----------------------------------------------------------------------| > | Ralph Zazula "Computer Addict!" | > | University of Arizona --- Department of Physics | > | UAZHEP::ZAZULA (DecNet/HEPNet) | > | zazula@uazhe0.physics.arizona.edu (Internet) | > |----------------------------------------------------------------------| > | "You can twist perceptions, reality won't budge." - Neil Peart | > |----------------------------------------------------------------------| Scott Bennett, Comm. ASMELG, CFIAG Systems Programming Northern Illinois University DeKalb, Illinois 60115 ********************************************************************** * Internet: bennett@cs.niu.edu * * BITNET: A01SJB1@NIU * *--------------------------------------------------------------------* * "Well, I don't know, but I've been told, in the heat of the sun * * a man died of cold..." Oakland, 19 Feb. 1991, first time since * * 25 Sept. 1970!!! Yippee!!!! Wondering what's NeXT... :-) * **********************************************************************