-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Somebody in the thread at some point said:
| blow up. The first register has normally bit 15 set (meaning | CMD-queue empty (?)) and when Glamo dies it's cleared. The second Command queue is some kind of mode thing for Glamo, we had trouble with it before and I put locking around the stuff that uses it, trouble went away. I see you are using the lock (unfortunately :-) ). | register seems to be the number of the line currently transferred by | the DMA to LCD. It's always 0x273 after death. 0x273 is the top row | of the last line of text in console, where the cursor is usually. The | next two registers are CRC count, it's interesting because the last | register (at 0x1186) contains some kind of checksum of everything in | the framebuffer, meaning that its value only changes when something | changes on the screen, I wonder if it can be used for something. | * all the other registers have their usual values. | * the death is related directly to the number of cursor changes since | bootup (not frequency) it seems. If I understood it the hw cursor is coming in on an interrupt, I would suspect a probability based problem where we blow up depending on what the foreground was in the middle of when we came in. But if it is a fixed number of cursor actions that doesn't fit. Also, these are just the LCD engine regs shown by default. The kind of issue you are seeing can be caused by crapping on the "General" set too, which has the clock generation stuff, so worth a look there. | I'll have some more play another day. OK, appreciated. This is more useful than it might appear because there is at least one probability-based problem with Glamo addressing corruption that is not understood. Currently it is worked around by maxxing out the waitstates to the Glamo which reduces its probability to "I didn't see it lately". But being able to not have to max out the waitstates to the Glamo if we ever did understand the issue has "obvious advantages". If you have another attack on it, I would start by #if 0 -ing out chunks of the hw cursor function and see if there is a point where removing something specific (even if you can't see the cursor move any more) stops the bad behaviour, then it can mayb make a clue. - -Andy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iEYEARECAAYFAkhHmOEACgkQOjLpvpq7dMpymACgkHMxwVsnfpaS6kG2a1P+kFte 6QwAnRjoW5q2etblLQtVMy89xLLv0oxJ =EmCJ -----END PGP SIGNATURE-----
