Well, everyone, here is an update. For several days the laptop worked fine without any problems, but a couple of days ago, I started having erratic problems. It seems to now be in state where it is easily broken, then fixed. Rebooting tends to clear up any problems at this point. I've tried Linux with nv and nvidia and Windows. More notes inline.
On 10/3/05, D. Hugh Redelmeier <[EMAIL PROTECTED]> wrote: > | 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? Looks like 4 pixels, but it's hard to tell. And that is the small stripe. There seems to be a bigger "stripe" that happens, I think it was 16 of the smaller stripes, so 64 pixels. > The memory bus is 64 bits wide. Pixels are either 24 or 32 bits I think I've got it 32 bpp in Windows, 24 bpp in Linux. > (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. No problem. Made enough sense to me :). > | 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"). Uhh, I've got an nVidia GeForce 440 Go that should have 64 MB of *discrete* memory. It is certainly not the shared memory system made popular by Intel graphics chipsets. I could image there being some buffers in memory, though. > 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" Got to this one when it was acting up (I normally use the framebuffer console). Characters displayed fine on the screen (no striping), but there was garbage covering most of the screen. So the character buffer was also getting corrupted somehow. > - (in most systems) BIOS setup mode. (Not sure how they get logos on > the BIOS screen.) Must be frame buffered somehow, because it striped. > - 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 Again, it may do some of this, but it should be to the same extent my desktop does with an MX440. At least, that is what I thought. > 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. Didn't see anything obvious when taking it apart. Some fine dust in places, not really near chips. > || > 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. Seems like everything is BGA, with which seems like this sort of thing would work less. I tried twisting it a little with it fully intact. Bends a little, but yeah, this thing is solid. > I have not tried the follow-on: a 4 inch (10cm) drop. Scares me. *cringe* > | > 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. This may have been correct, though it seems like there might be a few pixels out of place. > | 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. Got it for Fedora (very recent,so no problems). Ran it for a good hour. 4 passes and no failures. Certainly seems like the system RAM is okay. I guess I could run it longer. I still suspect video RAM or graphics processor. Does anyone know of a memtest-like program to check those? > | 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? No. X tries to start in runlevel 5, not 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. It was. Then it decided it would boot consistently. I don't get it either. > | > 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 :-( Perhaps. If I do scrap it, I thought I'd give some of y'all first dibs if you want since I know y'all could use them. > | 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? Plain text is messed up too, just differently. Text is garbled rather than the display image. Something is getting corrupted somewhere, that seems certain. [snip] > Play, record patterns of behaviour that emerge, form hypotheses, test, > ... Well, I have at least been able to do some testing. Getting strange results, though. It's really starting to look like something is wrong with the GPU. 3D seems to really give it trouble now. I installed 3DMark2001 SE to try and test it out, and it crashes with different video related errors after a little while (a few seconds) of running. The interesting thing here is that the screen doesn't garble in the same way. It actually can stay correct or it can go with the nVidia driver dying a horrible death (Windows). Screensavers and power-save modes seem to cause it woes too. Locked once when running a GL screensaver in Linux, hard lock, no screen scrambling, though some stray pixels I think. I just tried grabbing a screenshot when it went scrambled. I was able to open paint, paste, and save it. All I got was a big black rectangle. Things were looking good, but now not so good. I guess I could try Linux with nv to see if I can it to scramble there. If not, maybe it's time to go Linux-only with this laptop. Or I may end up with a rather portable headless server. I wonder if I could adapt the screen or keyboard for use elsewhere. Any more ideas? Jonathan _______________________________________________ LinuxR3000 mailing list [email protected] http://lists.pcxperience.com/cgi-bin/mailman/listinfo/linuxr3000 Wiki at http://prinsig.se/weekee/
