Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#9323 closed defect (fixed)

viafb corruption after switching from X back to viafb

Reported by: cjb Owned by: cjb
Priority: normal Milestone: 10.1.2
Component: kernel Version: 1.5 Software Build os206 aka 10.1.1
Keywords: Cc: dsd, HaraldWelte@…
Blocked By: Blocking:
Deployments affected: Action Needed: no action
Verified: no

Description (last modified by 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.

Attachments (2)

0002-Fix-fillrect-acceleration.patch (7.5 KB) - added by jon.nettleton 4 years ago.
Fix some previous Errors
0001-Only-reserve-memory-for-HWCURSOR-once.patch (1.2 KB) - added by jon.nettleton 4 years ago.

Download all attachments as: .zip

Change History (22)

comment:1 Changed 5 years ago by cjb

  • Description modified (diff)

comment:2 Changed 5 years ago by 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.

comment:3 Changed 5 years ago by Quozl

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

comment:4 Changed 5 years ago by 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?

comment:5 Changed 5 years ago by Quozl

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

comment:6 Changed 5 years ago by 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.)

comment:7 Changed 5 years ago by 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.

comment:8 Changed 5 years ago by triagebot

  • Milestone changed from 1.5-software to 1.5-software-final

changed by irc user cjb:

comment:9 Changed 5 years ago by cjb

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

comment:10 Changed 5 years ago by 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.

comment:11 Changed 5 years ago by 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.

comment:12 Changed 5 years ago by Quozl

  • Milestone changed from 1.5-software-final to 1.5-software-update

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.

comment:13 Changed 5 years ago by 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.

comment:14 Changed 4 years ago by 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.)

comment:15 Changed 4 years ago by 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.

comment:16 Changed 4 years ago by 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.

comment:17 Changed 4 years ago by cjb

  • Action Needed changed from diagnose to add to build
  • Owner changed from dsaxena to 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.

Changed 4 years ago by jon.nettleton

Fix some previous Errors

Changed 4 years ago by jon.nettleton

comment:18 Changed 4 years ago by dsd

  • Action Needed changed from add to build to test in build
  • Milestone changed from 1.5-software-later to 10.1.2

Thanks Jon, test in next 10.1.2 build

comment:19 Changed 4 years ago by dsd

  • Resolution set to fixed
  • Status changed from new to closed

confirmed fixed in 10.1.2 build 303 for XO-1.5

comment:20 Changed 4 years ago by Quozl

  • Action Needed changed from test in build to no action
  • Version changed from not specified to 1.5 Software Build os206 aka 10.1.1

Confirmed fixed in os303. Affected version 10.1.1.

Note: See TracTickets for help on using tickets.