Most recent kernel where this bug did not occur: Don't recall! Distribution: Gentoo-Linux Hardware Environment: AMD Athlon 64 X2 5600+, Asus Crosshair MB, 4GB Kingston Sli-Ready Hyper-X RAM, 2 x XFX nVidia GeForce 7900 GS (sli-setup) etc. Software Environment: Asus Crosshair Bios Rev. 702 (stable) ... first running terminal, then xorg-server build (on gentoo) Problem Description: `vesafb' module is compiled into the kernel. No problems with current or virtual terminals. First run of `startx' command is also fine. After shutdown and restart of x-server problem appears in form of a blinking cursor image on top of the `desktop' area in the upper left corner (I'll attach a snapshot). It makes no difference if same or other user with a new login restarts X. It makes no difference if binary-nvidia driver, nv or whatever else is used. It makes no difference if kde, gnome, xfce or plain old twm environment is used to build a workspace. It has nothing to do with resolution, monitor, cables ... neither with my current sli-setup, I've had the same symptom on a previous x86_64 single video card box. This broken framebuffer image goes away if during an open X session any `ctrl+alt+Fx' sequence is called to switch to a virtual terminal and back. Interestingly it differs when `vga16fb' is used instead?! No breakage, nothing! Besides that this out-dated module is ugly on the terminal, it also tends to mess up with current xorg-server builds ... my 11 year old son lost the video signal when he tried to quit an old DOS game running under `scummvm' ... which never happened with `vesafb' or a kernel build without any framebuffer device ... but that's another story, sigh! Please ask for any further information you might need to investigate this problem... Esenlikle, Mehmet Kemal Steps to reproduce:
Created attachment 12974 [details] Snapshot Snapshot picture (kde on gentoo, 1024x768)
Reply-To: akpm@linux-foundation.org On Thu, 27 Sep 2007 17:04:55 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=9093 > > Summary: Framebuffer breakage with vesafb on x86_64 > Product: Other > Version: 2.5 > KernelVersion: 2.6.22.7 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: Other > AssignedTo: other_other@kernel-bugs.osdl.org > ReportedBy: bug.hunter@gmx.net > > > Most recent kernel where this bug did not occur: Don't recall! > > Distribution: Gentoo-Linux > > Hardware Environment: AMD Athlon 64 X2 5600+, Asus Crosshair MB, 4GB Kingston > Sli-Ready Hyper-X RAM, 2 x XFX nVidia GeForce 7900 GS (sli-setup) etc. > > Software Environment: Asus Crosshair Bios Rev. 702 (stable) ... first running > terminal, then xorg-server build (on gentoo) > > Problem Description: `vesafb' module is compiled into the kernel. No problems > with current or virtual terminals. First run of `startx' command is also > fine. > After shutdown and restart of x-server problem appears in form of a blinking > cursor image on top of the `desktop' area in the upper left corner (I'll > attach > a snapshot). It makes no difference if same or other user with a new login > restarts X. It makes no difference if binary-nvidia driver, nv or whatever > else > is used. It makes no difference if kde, gnome, xfce or plain old twm > environment is used to build a workspace. It has nothing to do with > resolution, > monitor, cables ... neither with my current sli-setup, I've had the same > symptom on a previous x86_64 single video card box. This broken framebuffer > image goes away if during an open X session any `ctrl+alt+Fx' sequence is > called to switch to a virtual terminal and back. > > Interestingly it differs when `vga16fb' is used instead?! No breakage, > nothing! > Besides that this out-dated module is ugly on the terminal, it also tends to > mess up with current xorg-server builds ... my 11 year old son lost the video > signal when he tried to quit an old DOS game running under `scummvm' ... > which > never happened with `vesafb' or a kernel build without any framebuffer device > ... but that's another story, sigh! > > Please ask for any further information you might need to investigate this > problem... >
This looks like that the cursor timer was not deleted initially when switching to graphics mode. What was the last kernel where this bug did not appear? And can you try reverting this particular commit? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=acba9cd01974353294ecd0c750581a6707d1ebe1
(In reply to comment #3) > This looks like that the cursor timer was not deleted initially when > switching > to graphics mode. What was the last kernel where this bug did not appear? It was between 2.6.16 and 2.6.17 somewhere? I know, it's too vague, but honestly I don't recall ... sorry! > And can you try reverting this particular commit? > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=acba9cd01974353294ecd0c750581a6707d1ebe1 Thank you! Will do and report back, asap...
Your above mentioned commit is NOT included in either 2.6.22.7 nor 2.6.22.9, which I have installed too now ... so it cannot be the culprit for this particular syptom?! Please notice that (in continue to this irrelevance and out of curiosity) I've tried to reverse this patch from my local git clone, which failed at hunk 4! I've this blinking spot enough, so if you can give me any hint where to start ... although I hate it doing (Linus forgive me!) ... I'm ready for a `bisect' session ;)
(In reply to comment #5) > Your above mentioned commit is NOT included in either 2.6.22.7 nor 2.6.22.9, > which I have installed too now ... so it cannot be the culprit for this > particular syptom?! Hmm, I thought that was already part of 2.6.22... > > Please notice that (in continue to this irrelevance and out of curiosity) > I've > tried to reverse this patch from my local git clone, which failed at hunk 4! > > I've this blinking spot enough, so if you can give me any hint where to start > ... although I hate it doing (Linus forgive me!) ... I'm ready for a `bisect' > session ;) This usually implies that X may not have set the vc in KD_GRAPHICS mode, so the console thought it's still okay to show and blink the cursor. Try inserting this printk("vc%i blank %i mode %i active %i\n", vc->vc_num, blank, mode_switch, fbcon_is_inactive(vc, info)); as the first statement of fbcon_blank() in drivers/video/console/fbcon.c. Recompile, then switch back and forth a few times between X and the console, then send me the entire dmesg output.
If you meant ... static int fbcon_blank(printk("vc%i blank %i mode %i active %i\n", vc->vc_num, blank, mode_switch, fbcon_is_inactive(vc, info)); struct vc_data *vc, int blank, int mode_switch); ... that doesn't compile?!
No, look for the function fbcon_blank() in drivers/video/console/fbcon.c You should see something like the snippet below: static int fbcon_blank(struct vc_data *vc, int blank, int mode_switch) { struct fb_info *info = registered_fb[con2fb_map[vc->vc_num]]; struct fbcon_ops *ops = info->fbcon_par; if (mode_switch) { struct fb_var_screeninfo var = info->var; ops->graphics = 1; if (!blank) { if (info->fbops->fb_save_state) info->fbops->fb_save_state(info); var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_FORCE; .... Just insert the statement between: struct fbcon_ops *ops = info->fbcon_par; if (mode_switch) {
Thanks for your patience! ... I've done the hack, rebuilded the kernel (it's 2.6.22.9 now) and am attaching the requested `dmesg' block.
Created attachment 13025 [details] Full dmesg log The requested session log...
Okay, maybe I know what's going on, but I don't know why. The function con_blank() , besides blanking the console screen, also informs the underlying console drivers, such as fbcon, if there is an impending mode switch (from text mode to graphics mode and vice versa). So in your dmesg output, the first line is this: Oct 3 01:14:41 skepsis [ 438.483575] vc6 blank -1 mode 1 active 1 The combination of blank = -1 and mode = 1 is telling the console that it is switching the mode from text to graphics of vc6 (or tty7) which I believe X is located. So that's fine since X is a graphics application. And one of the thing that fbcon does is remove the cursor. However, several seconds later we have this: Oct 3 01:15:49 skepsis uptimed: moving up to position 27: 0 days, 00:08:03 Oct 3 01:16:00 skepsis [ 517.877845] vc6 blank 0 mode 1 active 1 Now, the combination of blank = 0 and mode = 1 is telling the console that the mode is switching from graphics mode to text mode in the tty where X is located. And one of the thing fbcon does when it is in text mode is restart the cursor. So you see the flashing cursor in the upper left of your screen. Why it does that, or who does that call, I don't know. So let's debug this a little more. Just after the printk(...) you added in fbcon_blank(), add this single statement: WARN_ON(1); This will give as a call tracing when fbcon_blank() is called, and hopefully we find out who's doing that illegal fbcon_blank() call.
And don't forget to post your dmesg again after adding the WARN_ON(1); statement.
Thank you very much for your detailed explanations! ... I've done what you requested and will attach the dmesg log with WARN_ON(1) in follow-up, but please note that ONLY two X sessions were recorded, whereas I called `startx' FOUR times in total?! Why aren't there any log entries for the latest two X sessions, no signs from the kernel responding to the `printk' & `trace_call' commands?!
Created attachment 13033 [details] Full dmesg log (debug) Please do NOT forget my above mentioned remarks about this log!
(In reply to comment #13) > Thank you very much for your detailed explanations! ... I've done what you > requested and will attach the dmesg log with WARN_ON(1) in follow-up, but > please note that ONLY two X sessions were recorded, whereas I called `startx' > FOUR times in total?! Why aren't there any log entries for the latest two X > sessions, no signs from the kernel responding to the `printk' & `trace_call' > commands?! That I don't know. You should get those printk's when switch from graphics to text and vice versa (ie, from X to tty0). I know in my box I do. Anyway, the tracing: Oct 4 04:27:47 skepsis [ 230.069948] [<ffffffff80427c42>] fbcon_blank+0xb2/0x2e0 Oct 4 04:27:47 skepsis [ 230.069952] [<ffffffff802873af>] do_lookup+0x8f/0x220 Oct 4 04:27:47 skepsis [ 230.069956] [<ffffffff802926f0>] dput+0xa0/0x130 Oct 4 04:27:47 skepsis [ 230.069958] [<ffffffff80289a8d>] __link_path_walk+0xb0d/0xec0 Oct 4 04:27:47 skepsis [ 230.069961] [<ffffffff802891ab>] __link_path_walk+0x22b/0xec0 Oct 4 04:27:47 skepsis [ 230.069965] [<ffffffff8046373f>] do_unblank_screen+0x9f/0x150 Oct 4 04:27:47 skepsis [ 230.069968] [<ffffffff8045c9ac>] vt_ioctl+0x175c/0x1990 shows one of your applications (maybe X, maybe some other) is requesting that tty7 should change to text mode (or specifically, ioctl(..., KDSETMODE, KD_TEXT);) As to why this did not show up in earlier kernels, that I'm also not sure. There is not much change done in this part of the kernel for some time. Perhaps if you have the patience and time to go back to a working kernel and add the same printk's and WARN_ON's...
In the meantime, one workaround to stop the cursor from displaying are: When in X: echo 1 > /sys/class/graphics/fb0/state When in the console: echo 0 > /sys/class/graphics/fb0/state
(In reply to comment #15) > > As to why this did not show up in earlier kernels, that I'm also not sure. > There is not much change done in this part of the kernel for some time. > Perhaps > if you have the patience and time to go back to a working kernel and add the > same printk's and WARN_ON's... > Besides that I know that a lot of people are affected ... I've promised my son to solve this annoying problem, so ... no chance to escape the burden ;) If you don't have any other proposal, I've looking at my local portage tree found 2.6.16.19 as the first & oldest vanilla-kernel build for the 2.6 series and would like to begin from there. Also to avoid future complications I would like to ask for the examination of my current kernel configuration before I'll go onto this journey ... if there is anything else you might want me to do, please let me know?!
Created attachment 13044 [details] Current kernel configuration (2.6.22.9) Please let me know if anything isn't kosher...
Your config looks okay to me. You might want to let the people who support your distribution know. Using the same test, I'm confident that nothing in my box sets X's vt to KD_TEXT. I'm using opensuse 10.2.
(In reply to comment #19) > Your config looks okay to me. > Thank you for the `review' ;) > You might want to let the people who support your distribution know. Using > the > same test, I'm confident that nothing in my box sets X's vt to KD_TEXT. I'm > using opensuse 10.2. > Sigh ... nevertheless, will do! In the meantime I've done some tests with previous kernel releases and made some preliminary progress, but there was a recent update of our toolchain and I've to rebuild major system dependencies, so bear with me please! I'll try to post the results asap...
OK ... I've done my homework ... here are the results: 2.6.16.19 -> good 2.6.17.14 -> good 2.6.18.8 -> good 2.6.19.7 -> bad 2.6.20.20 -> bad The above kernel releases were the latest in their representing version lines and also included in our `vanilla-kernel' tree. After finding out that something has became wrong for my setup with 2.6.19.7, I made a local overlay, compiled all previous releases from 2.6.19 up and began to go back from 2.6.19.7 testing ... The culprit for my problem begins with the rise of 2.6.19! Whatever was introduced and/or changed with 2.6.19, it triggers this framebuffer breakage?! Last note on my follow-up dmesg attachments: For every working or not-working kernel release I started X four times in every test-cycle, whereas on not-working kernels every X session was additionally interrupted with a `ctrl+alt+Fx' key sequence. Here we go ...
Created attachment 13091 [details] dmesg for 2.6.16.19 2.6.16.19 -> good
Created attachment 13092 [details] dmesg for 2.6.17.14 2.6.17.14 -> good
Created attachment 13093 [details] dmesg for 2.6.18.8 2.6.18.8 -> good
Created attachment 13094 [details] dmesg for 2.6.19 2.6.19 -> bad
Created attachment 13099 [details] Remove cursor timer on mode switch I still believe that what X is doing is wrong. It defies logic that a graphics application would tell the kernel that it is in text mode and still expect the kernel to behave as if it is in graphics mode. So the patch I'm attaching is hacky at best, designed to work around this strange behavior. It might even cause a regression with other people's setup. Let me know if it works for you. And if it does, it would still be prudent to inform whoever is responsible about this strange behavior.
(In reply to comment #26) > > I still believe that what X is doing is wrong. It defies logic that a > graphics > application would tell the kernel that it is in text mode and still expect > the > kernel to behave as if it is in graphics mode. > I can not follow you: If `its defies logic that a graphics application' is the culprit, why am I not able to reproduce `this strange behaviour' on a kernel with-out any special fbdev or on a kernel with vga16fb or even nvidiafb built?! Please do examine my follow-up attachments ... and btw (assuming that no major change was made to its own code) what triggers vesafb AFTER 2.6.19 to act so badly?! > > So the patch I'm attaching is hacky at best, designed to work around this > strange behavior. It might even cause a regression with other people's setup. > Let me know if it works for you. And if it does, it would still be prudent to > inform whoever is responsible about this strange behavior. > Thank you for the patch: It works, yes ... please see my last attachment in this line ... but even `if it does', forgive my ignorance, I do not understand why `this strange behaviour' is limited to vesafb?! This times last note on my follow-up attachments: I was eager to upgrade to yesterdays newest kernel release ... I hope you do not have any objections, though ;)
Created attachment 13117 [details] dmesg for 2.6.23 with any fbdev Kernel 2.6.23 compiled with any special fbdev module and previous `printk...' plus `WARN...' hacks applied
Created attachment 13118 [details] dmesg for 2.6.23 with vga16fb Kernel 2.6.23 compiled with vga16fb module and previous `printk...' plus `WARN...' hacks applied
Created attachment 13119 [details] dmesg for 2.6.23 with nvidiafb Kernel 2.6.23 compiled with nvidiafb module and previous `printk...' plus `WARN...' hacks applied
Created attachment 13120 [details] dmesg for 2.6.23 with patched vesafb Kernel 2.6.23 compiled with patched vesafb module and previous `printk...' plus `WARN...' hacks applied
(In reply to comment #27) > (In reply to comment #26) > > > > > I still believe that what X is doing is wrong. It defies logic that a > graphics > > application would tell the kernel that it is in text mode and still expect > the > > kernel to behave as if it is in graphics mode. > > > > I can not follow you: If `its defies logic that a graphics application' is > the > culprit, The ioctl(.., KDSETMODE, KD_GRAPHICS|KD_TEXT) is an instruction by a graphics application to the kernel that says 'Mr. kernel, I'm grabbing this tty, it is in KD_GRAPHICS mode, so don't touch it' and 'Mr. kernel, I'm releasing this tty, it is now in KD_TEXT so you can start writing text to it'). What's happening in your setup is the latter, but X hasn't released the tty yet. > why am I not able to reproduce `this strange behaviour' on a kernel > with-out any special fbdev or on a kernel with vga16fb or even nvidiafb > built?! For vga16fb, that's easy. The framebuffer address of the card is different when it is in VGA graphics mode (vga16fb) and when it is in true graphics mode. So that cursor is probably blinking somewhere, you just don't see it, either because the graphics layout has changed, or the cursor is located somewhere offscreen. As for nvidiafb, it is an accelerated driver (vs a dumb driver such as vesafb). nvidiafb relies on the 2D engine to draw the cursor. So when X's nv is active, it is holding the 2D engine and locks out nvidiafb. > Please do examine my follow-up attachments ... and btw (assuming that no > major > change was made to its own code) what triggers vesafb AFTER 2.6.19 to act so > badly?! I cannot pinpoint that exactly. But there was a fix in 2.6.19-rcx for a problem a bit similar to this. That fix (which is technically correct) must have exposed your problem. It's called a regression, and it does happen all the time. Kernel developers hate it (I hate it)... whether the culprit is the kernel or userspace. > > > > > So the patch I'm attaching is hacky at best, designed to work around this > > strange behavior. It might even cause a regression with other people's > setup. > > Let me know if it works for you. And if it does, it would still be prudent > to > > inform whoever is responsible about this strange behavior. > > > > Thank you for the patch: It works, yes ... please see my last attachment in > this line ... but even `if it does', forgive my ignorance, I do not > understand > why `this strange behaviour' is limited to vesafb?! Part of the explanation is mentioned above. Basically, vesafb is not dependent on the card's capabilities, and everything, including the cursor, is drawn using software. So, even if X's nv grabs the 2D engine, it hasn't stopped vesafb's software renderer. To truly stop it, the graphics application must tell the kernel it is in KD_GRAPHICS mode. > > This times last note on my follow-up attachments: I was eager to upgrade to > yesterdays newest kernel release ... I hope you do not have any objections, > though ;) > No problem :). I'm extremely grateful to you for following up on this problem in such a persistent manner. If all reporters were like you, we'll fix all kernel bugs in no time :) The patch, after giving it some thought, is probably of low impact. So, I'll push this patch upstream for 2.6.24. Probably not for 2.6.23 stable, as there's still a low probability for regressions. Once again, thanks.
BTW, I checked your latest attachments. Yes, you're still going to get those WARN_ON's. The patch cannot stop userspace, but it can stop some of its ill-effects.