| From: Jonathan Berry <[EMAIL PROTECTED]> | > I wonder what could be wrong. It looks as if 1/2 of the vertical | > stripes are correct and the other half are wrong in some way. Perhaps | > you can figure out what is going on from the pattern. I cannot make | > out the pattern from your picture. | | Not easily. It does look like there are stripes that are affected and | some that aren't. Like an address line problem somewhere.
The pattern is a signature of the problem. That does not mean that we know enough to read the signature. How wide are the stripes? Probably a power of 2. 8? The memory bus is 64 bits wide. Pixels are either 24 or 32 bits (probably 32). L2 cache lines are 64 bytes wide. The HTT bus is 16 bits wide. Any of these, or something else, might dictate a stripe width. http://www.sandpile.org/impl/k8.htm | > I don't think your RAM is bad for a couple of reasons. Even so, if | > you have two sticks, try each alone. | > | > Maybe your RAM is bad. How many sticks do you have? If two, try each | > alone. That's coherent, isn't it :-) I edited my message a lot while thinking about your problem. I missed this part. | Just one. I was going to buy a 1 GB stick, but now I don't know if it | will do me any good. So, how could bad RAM do this? | | I know there is | an AGP aperture (I think that is the term) in RAM, but I'm not really | familiar with how that works. Is there a screen buffer that resides | in (system) RAM? I'm more concerned about the graphics RAM, which is | not replicable. The pixels for the screen are held in RAM. The "frame buffer" could be separate memory chips, but it isn't on our systems (the euphamism is "unified"). In the old days (think DOS, without graphics) the frame buffer actually only held an array of characters; the video chip, on the fly, as it refreshed the screen, used a character generator to paint the pixels based on the characters in the frame buffer. This capability still lives in modern hardware, but it is rarely used. Here are some cases where it is used: - plain DOS - console-mode Linux (init level 3 or single user mode), but only if *not* using the "frame buffer console" - (in most systems) BIOS setup mode. (Not sure how they get logos on the BIOS screen.) - memtest86 or memtest86+ In normal graphics mode, our system's video chip fetches various things from the RAM it shares with the rest of the system. I don't know them all, but they include: - frame buffer - off-screen buffers of images - fonts - textures This howto explains the freamebuffer console, I think. This is what you don't want. Well, maybe as an additional experiment: http://en.tldp.org/HOWTO/Framebuffer-HOWTO.html Might be obsolete. Another oldie: http://www.digitalhermit.com/linux/hiresconsole.html | > If chips were in sockets, I'd say that you should try reseating them. | > But I don't think much is in sockets these days. | | Nope. See the "internals" dir for pictures. All soldered on. Another longshot: any chance for a conductive crumb being lodged somewhere? Shaking, knocking, tipping can sometimes dislodge something like that. || > the "Atari Twist" | Interesting idea. Had not heard that one. So, twist the entire | computer then? With everything intact? This thing's pretty solid, I | don't know how much things could bend. I don't either. But I can vouch that it has worked on some (other) systems. I have not tried the follow-on: a 4 inch (10cm) drop. Scares me. | > That suggests the problem is not RAM: I think that the BIOS uses the | > frame buffer in a quite different way. On the other hand, in your | > third picture, the plain text messages "Press <Esc>..." look intact. | | Uhh, they are more than other parts of the screen, but I think there | is some distortion, though. Hard to tell. I don't expect that there was (spatial, continuous) distortion when viewd on LCD. Distortion is pretty hard to arrange. | No floppy. Frame buffered console shows the same problems. GRUB | shows large bands where things are messed up. You can get a .iso of memtest86+. Burn to create a bootable CD (mostly empty). http://memtest.org (not memtest86.com). This uses the screen in good old text mode. Some Linux distros include memtest86+ on their installation disk (Knoppix and Fedora, for example). Beware: some old versions of memtest86+ didn't work on our machines. | I actually got it to boot a couple of times now. Booted into Linux | runlevel 5. Lost it when X tried to start. Do you mean runlevel 3? How often can you boot successfully (I mean: at least to the point of BIOS messages)? Your previous post sounded as if you were in the "rarely if ever" region. | > I haven't looked for this, but ebay seems to have partial laptops and | > laptop parts. | | Maybe. Again, I do not care to spend a whole lot of money. You could also sell there :-( | Okay, what the.... It just came back perfect! Booted to runlevel 3, | did some backup, edited xorg.conf to use "nv" driver (since nvidia | seemed hopeless) That sounds like plain text mode console (but I cannot be sure that you are not using the frame buffer console). That might always have been working -- do you know? | and did an init 5. The screen froze in a scrambled | state, but the mouse pointer was fine and could move around. Reboot | and... everything seems fine. Do I dare try nvidia again? Or boot | Windows? Or reboot at all? No idea. I've never used nvidia. For variety, I wonder if you can try VGA. I know, not at a nice resolution. | It did come back once before after | messing up, but after about 10 minutes of using Windows, it reported | that the nVidia driver caused a problem and the screen scrambled up. | How can this problem be so persist ant and then transient like this? | I don't guess I have anything to lose. If it isn't going to be | consist ant, it might as well be broken. I suppose I could try out | memtest for a while in case it is the RAM. Any other thoughts or | ideas? I guess let's hold off on that parts auction for now... Play, record patterns of behaviour that emerge, form hypotheses, test, ... _______________________________________________ LinuxR3000 mailing list [email protected] http://lists.pcxperience.com/cgi-bin/mailman/listinfo/linuxr3000 Wiki at http://prinsig.se/weekee/
