viafb corruption after switching from X back to viafb

[cjb]

To reproduce:

• wait for X to start
• hit ctrl-alt-f2 to go back to VT
• a red line appears at the bottom of the VT, and once you scroll down to the bottom new lines all have a red background.

[jon.nettleton]

The work-around for this problem is to add viafb_accel=0 to the video= option in /boot/olpc.fth.

Knowing this is a problem with the acceleration path should also help in tracking down the problem.

[Quozl]

This hasn't been seen on recent builds, and there has been much change that may relate. Can we close this one?

[cjb]

I can reproduce on os42, and don't have an os43 machine here at home. I don't see what in os43 would have fixed it. Can you re-test?

[Quozl]

Will do. Don't recall a Red Line, though I do recall once seeing non-black background.

[Quozl]

On os43 with B2 a similar symptom can be reproduced.

On switching to VT 1 a white or grey line is visible vertically underneath the console text output. The rest of the screen has a black background. Hitting Control/L (clear screen) at the shell prompt causes the rest of the background to adopt the same colour.

Adding viafb_accel=0 prevents the symptom.

(Using a sample data set of "find /usr > file" which is 37549 lines, and then timing "cat file"; with acceleration the time is 2min 28sec, without 4min 18sec. In Terminal in X it is 19sec regardless of acceleration.)

[dsd]

Yes, that's exactly the bug in question. It has not been fixed. The colour that spills onto the console seems to be from X - i.e. if there is a lot of green on the screen then the background on the shell changes to green.

[triagebot]

changed by irc user cjb:

[cjb]

Dan, think we need to fix this? Turning off accel might slow down bootanim.

[dsaxena]

My opinion on this is that this is low priority based on the assumption that in general our end users (the children) will not be switching to a tty.

[dsd]

I think turning off accel isn't an option as everything goes veeeeery slooooooow.

I agree that the effects of this bug itself aren't important, but I still worry a bit - the last viafb bug I found happened because we were scribbling random memory into the video command ringbuffer. Not a good idea.

I guess it's something we should hope to look at, but also accept that we have more pressing issues.

[Quozl]

Ticket moved out of 1.5-software-final to 1.5-software-update as a result of a software manufacturing release triage meeting. Per ed, dsd, cjb, reuben, quozl.

[mikus]

Problem is still there with os64 - though the disruptive color is more often white or gray.

Easiest way to see the problem is to log in to the VT, then use vi on some text file. The "remaining positions" between where a text line ends, and where the screen line ends, will show up in the disruptive color.

[pgf]

the problem still exists in os121, but it now gets cleared up after the first suspend/resume cycle. (i.e., the background goes all black on resume.)

[jon.nettleton]

Turns out we weren't actually getting acceleration. With this patch my testing shows about a 33% speedup. Oh and no more framebuffer corruption.

[jon.nettleton]

I added this patch as they can get reviewed together. Occasionally I would get a black square in the upper left corner of my xorg screen. You don't notice this in sugar because the upper left corner is always black. Only reserving cursor memory once fixes it up.

[cjb]

These look good to me; please fix the indentation and extra braces in the:

+    } else if (reg < ARRAY_SIZE(via_eng_reg))
+		reg = via_eng_reg[reg];

hunk, and we might as well s/Reverse/Reserve/ in the comment on the second patch, even though that was already mis-spelled upstream before you moved it.

Perhaps mail these over to linux-fbdev@ for upstream review too? We should also get them in an unstable build for testing.

[jon.nettleton]

Fix some previous Errors

[dsd]

Thanks Jon, test in next 10.1.2 build

[dsd]

confirmed fixed in 10.1.2 build 303 for XO-1.5

[Quozl]

Confirmed fixed in os303. Affected version 10.1.1.