This is a strange bug, and appeared with the 2.6.19 kernel. What happens is that the "flashing underscore" prompt that appears in the framebuffer just before xorg starts, keeps flashing after xorg started. The difference is that now it has several "mirrors" evenly distributed trough the top edge of the screen, suggesting that there are two processes using the same screen memory, but with different resolutions. It will be easyer to demonstrate the effect by a screenshot of the top edge of my screen: http://www.fe.up.pt/~ee03191/fbbug.png I'm using vesa-tng and it happens most of the time. I say most of the time because very few times it doesn't happen, just as if the problem only occured if the underscore was "on" in a particular time in xorg loading. When using the normal vesa framebuffer without any parameter (defaults to 640x480) the problem doesn't happen. My gfx card is a nvidia FX 5200. I'm using the latest nvidia-drivers, but nothing changes when using the previous version of the drivers, so I suspect it has nothing to do with these. I have lots of suspicions about where the problem may be originated, but I guess I need help from more experienced people. My grub kernel options: kernel /boot/kernel-2.6.19-gentoo-r4 root=/dev/hda1 \ video=vesafb:1024x768-32@70,mttr:2,vram:8 \ splash=silent,fadein,theme:emergence quiet CONSOLE=/dev/tty1
Please, attach any relevant files here; the bug becomes useless as soon as those vanish from third-party temporary links.
Maybe also try disabling fbsplash to see whether it affects this issue in any way.
Created attachment 106800 [details] screenshot from the top edge of the scren
(In reply to comment #2) > Maybe also try disabling fbsplash to see whether it affects this issue in any > way. > Just disabling it doesn't change anything. I'm recompiling the kernel without support for it right now. I'll post the results soon.
Nop, it has nothing to do with framebuffer. On the other hand, here's the output from "dmesg| grep fb": vesafb: unrecognized option mttr:2 vesafb: unrecognized option vram:8 vesafb: NVIDIA Corporation, NV34 Board - c116dnz , Chip Rev (OEM: NVIDIA) vesafb: VBE version: 3.0 vesafb: protected mode interface info at c000:f090 vesafb: pmi: set display start = c00cf0c6, set palette = c00cf130 vesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7 3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da vesafb: VBIOS/hardware supports DDC2 transfers vesafb: monitor limits: vf = 160 Hz, hf = 71 kHz, clk = 110 MHz vesafb: scrolling: redraw vesafb: framebuffer at 0xf0000000, mapped to 0xf8880000, using 24576k, total 131072k fb0: VESA VGA frame buffer device vesafb doesn't recognize the mttr option. Yet, the nvidia driver is compiled with mttr support. May this have anything to do with this memory race? Also, mttr and vram are documented in the kernel for both normal vesa and vesa-tng. It's strange that they're not being recognized..
OPS: vram is not available anymore, and "mttr" is in fact "mtrr". But then mtrr:2 forced me to go fetch my live CD... I feel like an idiot. Anyway, it has nothing to do with these two options either....
I found a way to fix the problem after it appears. If you switch to another VT and then switch back to xorg, the flashing underscore is gone. It seems like the fb isn't being "turned off" when it should..
Does this problem appear when using the standard vesafb driver? Could you please post your kernel config?
It doesn't happen with the standard vesa fb, at least in 640x480 mode. I'll try using a higher resolution mode. My kernel config will go on annex..
Created attachment 108293 [details] My current kernel config
(In reply to comment #9) > It doesn't happen with the standard vesa fb, at least in 640x480 mode. I'll try > using a higher resolution mode. I'm sorry but this isn't true. I assumed omitting the vga parameter would default to 640x480, but it did not. It just wouldn't bring up the framebuffer. I tried several modes, including 0x300, and the problem showed up on all of them. So it's not a vesa-tng problem, but a general framebuffer problem. Sorry Michal..
What was the last kernel version with which it did work properly?
It was working ok with gentoo-sources-2.6.18-r3. I was delaying the update to 2.6.19 for when a patch for reiser4 was available. I did test without the reiser4 patch, and the problem was still there. Strangely enough, some people are now complaining in the forums about other problems with nvidia AGP cards (no problem with PCIe).
(In reply to comment #0) > This is a strange bug, and appeared with the 2.6.19 kernel. What happens is > that the "flashing underscore" prompt that appears in the framebuffer just > before xorg starts, keeps flashing after xorg started. The difference is that > now it has several "mirrors" evenly distributed trough the top edge of the > screen, suggesting that there are two processes using the same screen memory, > but with different resolutions. I have the same problem as you. Upgraded from 2.6.18-r6 to 2.6.19-r5 and there is the same framebuffer problem. I also use vesa-tng. My login manager is qingy, which uses Framebuffer via DirectFB. Sometime that "flashing underscore" appears in qingy and is also present in X and the other time in qingy there is no uderscore but in xorg it suddenly appears. And sometime the problem does not appear at all (like this time i booted). A screenshot follows the next time the problem shows up. But i can describe it in advance. In the upper left corner there is this "flashing underscore" which is just like a text cursor from a tty. And like Renato in xorg i tried to switch to another VT and voila: The text cursor disappeared. My grub options are: kernel /boot/kernel-2.6.19-r5 root=/dev/hda9 vga=0x317 video=vesafb:mtrr,ywrap
I also use qingy, but the problem still happens if I login to a console and run startx. This is one thing we have in common.. Do you have a nvidia card? FX5200? I'll try not starting qingy on the next reboot, and will see if it continues to happen..
Ok, so this is what I found: *if qingy is started, the problem will appear, even if I login from a plain agetty. * if qingy is not started at all, then the problem goes away! So it may be an interaction between qingy and DirectFB.. it happened before..
Created attachment 109133 [details] Screenshot from top edge of the screen as promised
(In reply to comment #16) > *if qingy is started, the problem will appear, even if I login from a plain > agetty. > > * if qingy is not started at all, then the problem goes away! > > So it may be an interaction between qingy and DirectFB.. it happened before.. > Hm, may be we should file a bug report to qingy as well then.
I've added Noberasco to the CCs, so it should be the same thing :) In the meanwhile I'll try to see if it's just qingy or if another DirectFB app can cause it.
*** Bug 165471 has been marked as a duplicate of this bug. ***
I can reproduce the cursor issue in qingy and xorg too, but since this seems to happen on 2.6.19 only, I do not think it is a qingy bug... Anyway, I analized what processes are have some /dev/tty* open on my machine: here are the results: (1) qingy sitting inactively on a tty is the only process using that tty unless the user is running gpm, in which case gpm has open the same tty of the latest qingy that the user activated (by switching to its tty) (2) qingy with an X server running share the same tty Point (2) would be suspicious to me if the submitter didn't report that he has the issue even starting X from startx (which makes X come up in an unused tty). Neverthless, I'll try to detach qingy from the tty before firing up the X server and see what happens...
I did some tests with qingy but so far I haven't been able to reproduce the problem. Could someone please check whether they can reproduce it with a vanilla 2.6.20 kernel?
It doesn't happen with 2.6.20-gentoo. I guess it was just a quirk of 2.6.19.. Apparently problem solved.. I still have to wait for the reiser4 patches for vanilla though. Or maybe changing to mm wouldn't be bad.. Anyway, thanks for your time guys!
(In reply to comment #22) > I did some tests with qingy but so far I haven't been able to reproduce the > problem. Could someone please check whether they can reproduce it with a > vanilla 2.6.20 kernel? > Michal, I have tried everything possible: It has nothing to do with `qingy' or the default kernel-vesa-fb (running on my amd64-box)! I have even attempt to build & run all available `gentoo-' & `git-kernels' from 2.6.19 on, with the obscurest kernel configurations ... no, problem exist! If you are interested, I am ready to flood you with my observations ;)
Mehmet: If the problem is gone, I guess there's no need to do so :) Closing the bug as FIXED. Please reopen if you encounter this issue with 2.6.20.
Sorry for being confusing, but there was a (little) comma between: no [...] problem exist! Btw, I hate this language ;) Summary: Package `qingy' is installed, didn't like it, not using. Since kernel revision 2.6.19 `xorg-server' behaves in the way as described. First run is fine, second `startx' call encounters a broken fb-image (blinking cursor) on the top left corner. Switching between the terminals (ctrl+alt+fx <-> ctrl+alt+f7) cures it indeed. I have both `2.6.20-gentoo' and `2.6.20-git1' installed (and the first running). I have tested any available kernel configuration. I have even tried it without any fb enabled. NACK! ... It must have been a new problem with the `evdev-subsystem': When enabled `fb-splash' hangs this box when I missed to hit `f2' until the middle of the boot process! It's bed time here (05.50 in the morning) ... if you need any further information, ie lspci, dmesg and/or snippets from messages, xorg-logs, kernel-configs ... wait, bootchart is also running ... let me know ;)
(In reply to comment #26) > Sorry for being confusing, but there was a (little) comma between: no [...] > problem exist! Btw, I hate this language ;) [snip] > Summary: Package `qingy' is installed, didn't like it, not using. Well, it appears that qingy has nothing to do with this bug, after all. Feel free to re-add me if necessary.
Not being the initial reporter of this bug, I am unable to give it a `reopened' status: Master Jakub ... help, please ;)
I am the initial one :)
Thank you -> Master Renato ;)
Yes, the problem is still there.. I've switched to 2.6.20 today, and to my horror the flashing underscore showed up..
By the way, and just to clarify things, are we all (those who experience the problem) using a nvidia card? Also, Mehmet you said you had qingy installed but not running. Do you have it activated in some tty or just have agetty in all of them?
Please excuse my being late ... I'm *still* struggling with `libata' & friends :( > ... and to my horror the flashing underscore showed up.. Hehe, welcome back! ... <- Schadenfreude P) > ... using a nvidia card? Yup: lspci | grep VGA 05:00.0 VGA compatible controller: nVidia Corporation NV43 [GeForce 6600 GT] (rev a2) Albeit, I don't think that it's related ... or have you changed your hardware in between? > ... qingy ... activated in some tty or just have agetty in all of them? No: grep agetty /etc/inittab c1:12345:respawn:/sbin/agetty 38400 tty1 linux c2:12345:respawn:/sbin/agetty 38400 tty2 linux c3:12345:respawn:/sbin/agetty 38400 tty3 linux c4:12345:respawn:/sbin/agetty 38400 tty4 linux c5:12345:respawn:/sbin/agetty 38400 tty5 linux c6:12345:respawn:/sbin/agetty 38400 tty6 linux #c1:12345:respawn:/sbin/agetty 38400 tty1 linux #s0:12345:respawn:/sbin/agetty 9600 ttyS0 vt100 #s1:12345:respawn:/sbin/agetty 9600 ttyS1 vt100 Again, I don't think that it has anything to do with `qingy' ... it's up to our `xorg-server' (application family beast) *and* the whole underlying kernel userspace event system which takes care of such input requests ... lately there are major changes made to this event-subsystem, namely `acpi' is proceeding to own all of the `bus configuration scheme', so is `sysfs' going to be discharged in favour of a `proc' only system ... thus `we' might belong to a minority of lucky linuxen which are benefiting from such early development snippets in the latest kernel distribution ;) Either if it's a bug and/or `we' triggering this bug and/or `we' are all f*cked up ... please help me finding the similarities of `our' setups: 1. lspci -vv 2. dmesg 3. config-2.6.20-gentoo 4. genlop -i xorg-server 5. xorg.log Tia :)
Created attachment 111273 [details] Output of lspci -vv (Philipp)
Created attachment 111274 [details] Output of dmesg (Philipp)
Created attachment 111276 [details] .config of gentoo-sources-2.6.19-r5 (Philipp)
Created attachment 111278 [details] Output of genlop -i xorg-server (Philipp)
Created attachment 111280 [details] xorg.log File (Philipp)
I'm sorry for the delayed answer.. I'm not at home right now, but I can definitely see a pattern here. And it does confirm some of my later suspicions. Correct me if I'm wrong but here's the pattern: -Nvidia gfx card -nvidia proprietary drivers -kernel agpgart module The thing is, I found recently that the nvidia agp module messes up the console display after exiting xorg. So I tried swicthing between nvidia and "gart" modules by changing the xorg.conf file to see. Obviously I missed the fact that once the agpgart was compiled statically the nvidia module was never used. Even so, the change in one direction always made the bug disappear: MOD1 -> MOD1 - problem shows MOD2 -> MOD2 - problem shows MOD1 -> MOD2 - problem shows MOD2 -> MOD1 - problem disapears I don't remember which module is which, but I can check that out once I'm home. The point is, doing the MOD2 -> MOD1 change should trigger some kind of reset, and maybe that reset is the clue we need. Does this make any sense?
(In reply to comment #39) > The thing is, I found recently that the nvidia agp module messes up the console > display after exiting xorg. So I tried swicthing between nvidia and "gart" > modules by changing the xorg.conf file to see. Obviously I missed the fact that > once the agpgart was compiled statically the nvidia module was never used. Just to clarify myself, I always used the agpgart module. I just tried the nvidia module to see if agpgart was the culprit, except the nvidia agp module produced a worse problem (and finding this problem was a consequence of the above tests).
> Correct me if I'm wrong but here's the pattern: > -Nvidia gfx card > -nvidia proprietary drivers > -kernel agpgart module No, that is not correct, I have ATI Radeon 9200 with opensource drivers and never had any NVidia HW/drivers here. I have 2.6.19-gentoo-r5, will try with 2.6.20 and post some sysinfo as soon as I have enough time & will to do it...
I believe it's fixed now with DirectFB 1.0.0. I don't know what was the bug, but its fix may be related to Vaclav Slavik's VT fixes in RC3. I'll close it now, but will reopen if required. On the other hand qingy's gentoo theme is now a bit broken, but that's a different story. Cheers, Renato
