When I use scrollback (Shift+PageUp) in gentoo-sources-2.6.11-r4 with framebuffer (vesafb-tng) one symbol disappear from screen. Position of this symbol equal to cursor position before Shift+PageUp pressed. More precisely, not disappeared but replaced by symbol which was under cursor before Shift+PageUp pressed. I've switched to 2.6.11 from 2.6.8, so probably this issue exists in 2.6.9/2.6.10 kernels too. After looking kernel sources I notice major changes in framebuffer/cursor related code between 2.6.9 and 2.6.10 and nearly no changes between 2.6.10 and 2.6.11, so probably this bug exists in 2.6.10 too. I make a patch which fix this bug, but I'm neither kernel nor C guru, so there is a chance it fix this bug only partially or broke something else (patch attached). But even if this patch is bad, there something wrong in that part of kernel, just look at this simple example: #drivers/video/console/fbcon.c:1130 y += softback_lines; but modified "y" never used. Reproducible: Always Steps to Reproduce: 1. boot kernel with framebuffer (I use vesafb-tng, 1280x1024-16@85, without bootsplash and with kernel logo) 2. for i in $(seq 1 100); do echo $i; done; cat >/dev/null 3. press Shift+PageUp Actual Results: No symbol exists at bottom left corner. Expected Results: Symbol in bottom left corner should exists (it was generated by echo command).
Created attachment 56111 [details, diff] framebuffer scrollback cursor fix 2.6.11
I'm not sure is this relate to my patch, but my kernel just hangs after pressing Shift+PageUp in framebuffer console. There was no kernel oops/panic printed to console or logs, it just stop responding to keyboard. Xorg with ati-drivers was running at same time in different console. After reboot (hardware reset) I try to repeat this hang by testing Shift+PageUp mixing with switching between consoles and X - everything works fine.
It just hangs again after Shift+PageUp pressed. I've removed my patch from kernel and will wait for your comments...
Please try gentoo-sources-2.6.10-r4 and tell me what happens.
If you have some free time, you might want to try the latest vanilla-sources (just compile it with the config you used for gentoo-sources) and see whether the problem exists there as well. Are you using ypan or ywrap or just the default redraw method? (vesafb options)
There no gentoo-sources-2.6.10-r4 ebuild in portage (I use snapshot from 27 Mar). I've just tested gentoo-sources-2.6.10-r6 and this bug exists there. I'm usually use "video=vesafb:ywrap,mtrr fbcon=scrollback:128K", but for testing this bug I boot kernel both with and without all these params - bug exists in both cases. I'm going now to try vesafb (not vesafb-tng) and vga16fb drivers. Then I wish to try vanilla-sources 2.6.10 and 2.6.9 with vesafb.
I tested all of them: - bug exists with any driver: vesafb-tng, vesafb, vga16 - without framebuffer (I've booted with vesafb driver and "vga=0") bug disappear - vanilla-2.6.9 don't have this bug, vanilla-2.6.10 with same .config as 2.6.9 (vesafb driver, "vga=31b") have this bug So, looks like my initial assumption was 100% correct: - this bug introdiced while significant code change between 2.6.9 and 2.6.10 - this bug in main framebuffer code, not in one of drivers I think my patch correctly point to place in code with bug, but maybe incorrectly fix it. Maybe if somebody with better kernel/C knowledge just look at my patch and the sources then he make correct patch in 5 minutes... :)
The bitblit.c code in 2.6.12-rc2 seems to be fixed in a way very similar to what your patch does. Could you please give it a try? Maybe the problem is already fixed in 2.6.12-rc2.
Thanks. I've backported changes from 2.6.12_rc2 related to this issue to 2.6.11 and it fixes the bug. But I not sure is this patch also will hang my kernel... :) Anyway, I will attach that patch here because it should be better than my previous patch.
Created attachment 56305 [details, diff] Patch for 2.6.11 (backported from 2.6.12_rc2).
Alex: have you tested the new patch? Is it safe? Daniel: if the patch turns out to be safe, do you think we should include it in gentoo-sources-2.6.11?
Yep. It safe and works fine. I'm using it now with linux-2.6.11-hardened-r1.
Oops, didn't mean to reassign.
Fixed in gentoo-sources-2.6.11-r10