lkml.org 
[lkml]   [2008]   [Jul]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectPROBLEM: uvesafb broken as of Linux 2.6.24.x
Hello,

I see a weird problem with uvesafb and any recent Kernel. It seems like
the problem was introduced in some higher 2.6.24 version. I have more
information regarding this, but I will first explain the problem(s) I
experience.

After booting a faulty Kernel, these messages appear in my Kernel log
ring buffer ("dmesg"):


[ 112.816609] uvesafb: mode switch failed (eax=0x2104, err=0). Trying
again with default timings.
[ 112.819540] uvesafb: mode switch failed (eax=0x2104, err=0)

Please note, that these messages are the first ones after having booted
the box. (Due to the init scripts, the VT was automatically switched to
VT7 where X resides, after that I switched back to VT1.)

Switching to other VT's does *not* reproduce the warning/error messages.

Now to the interesting part.

When starting any program that needs framebuffer support (which is why
we use uvesafb, isn't it?), there messages re-appear. I have tested
mplayer with -vo fbdev or fbdev2 for example, on VT2. Starting it,
playing a (video) file for some seconds and looking at dmesg again,
these are the results:

[ 564.757398] uvesafb: mode switch failed (eax=0x338, err=0). Trying
again with default timings.
[ 564.758358] uvesafb: mode switch failed (eax=0x2104, err=0)
[ 564.838390] uvesafb: mode switch failed (eax=0x344, err=0). Trying
again with default timings.
[ 564.844749] uvesafb: mode switch failed (eax=0x2104, err=0)
[ 564.929364] uvesafb: mode switch failed (eax=0x104c, err=0). Trying
again with default timings.
[ 564.937509] uvesafb: mode switch failed (eax=0x2105, err=0)
[ 565.021358] uvesafb: mode switch failed (eax=0x42b, err=0). Trying
again with default timings.
[ 565.027047] uvesafb: mode switch failed (eax=0x2105, err=0)
[ 565.109331] uvesafb: mode switch failed (eax=0x32b, err=0). Trying
again with default timings.
[ 565.111679] uvesafb: mode switch failed (eax=0x2105, err=0)
[ 565.194323] uvesafb: mode switch failed (eax=0x2104, err=0). Trying
again with default timings.
[ 565.195379] uvesafb: mode switch failed (eax=0x2104, err=0)
[ 565.278306] uvesafb: mode switch failed (eax=0x2104, err=0). Trying
again with default timings.
[ 565.280417] uvesafb: mode switch failed (eax=0x2104, err=0)
[ 571.548365] uvesafb: mode switch failed (eax=0x2104, err=0). Trying
again with default timings.
[ 571.555713] uvesafb: mode switch failed (eax=0x10032b, err=0)

Additionally, the console does not work anymore and is totally
blank/black (and I did not even see a video. However, this last point is
not a "symptom" one can experience anytime, the video playback might or
might not work, it is indeed some sort of luck.)
"Recovering" from this situation is a little bit complicated. I have
found following solutions:

- Switch to the first VT (or any other, but it seems to be important,
that this VT has not been used in the means of framebuffer) and then to
the "old" VT again. Doing so you might get eventually any text again,
but again, it is a piece of luck. Especially on high CPU and IO load
this might not work and leave all your consoles blank. Also, you *must
not* move too quick from one console to another or the problem might not
disappear as well. However, I have spent several minutes doing this
method and it just... s*cks.
- Switch to the VT where X is running (this is working almost every
time, for details see below) and after that to your desired "old" VT.
This method has higher success chances than the other one, but depending
on the load of the box, you really might need several minutes to get any
text again.
- It happened now and then to me, that I was not able to switch back
to the X-VT or any other. The box was still running, no Kernel Panic or
Ooopses happened, but there was no way to get it back to work (on any
VT, including the one with Xorg.) Even restarting Xorg did not help
anymore and the last and only measure to take was rebooting the box.

Okay, that is the situation when using any framebuffer content.

But also without framebuffer usage, the "blank console" problem can hit
you and you have to do one of the steps listed above in order of being
able to use the box again graphically. (Not mentioning SSH and the like,
those work without any problems, of course.)

I cannot stress this too much, please keep in mind, that all the
problems aggravate on high load. I think this is important, you will now
see why.


I have got a copy of Linus' Linux-git tree and ran the bisect routine. I
knew that the problem was introduced between 2.6.24.2 and 2.6.25, so I
build and tested like 13 different kernels in this range.
Finally, I have been able to find the faulty patch... and was quite
astonished. This is git's result:

8f4d37ec073c17e2d4aa8851df5837d798606d6f is first bad commit
commit 8f4d37ec073c17e2d4aa8851df5837d798606d6f
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Fri Jan 25 21:08:29 2008 +0100

sched: high-res preemption tick

Use HR-timers (when available) to deliver an accurate preemption tick.

The regular scheduler tick that runs at 1/HZ can be too coarse when nice
level are used. The fairness system will still keep the cpu
utilisation 'fair'
by then delaying the task that got an excessive amount of CPU time
but try to
minimize this by delivering preemption points spot-on.

The average frequency of this extra interrupt is sched_latency /
nr_latency.
Which need not be higher than 1/HZ, its just that the distribution
within the
sched_latency period is important.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Signed-off-by: Ingo Molnar <mingo@elte.hu>

:040000 040000 ab225228500f7a19d5ad20ca12ca3fc8ff5f5ad1
f1742e1d225a72aecea9d6961ed989b5943d31d8 M arch
:040000 040000 25d85e4ef7a71b0cc76801a2526ebeb4dce180fe
ae61510186b4fad708ef0211ac169decba16d4e5 M include
:040000 040000 9247cec7dd506c648ac027c17e5a07145aa41b26
950832cc1dc4d30923f593ecec883a06b45d62e9 M kernel

Do you see, what I mean? Obviously it is no bug in uvesafb itself (at
least no uvesafb code has been changed, that is) but introduced by this
Preemption patch. This might explain the problems concentrating on high
load (but not only in this status, though.)

Now, to be honest, I am a little bit puzzled about whom to contact. It
might be a bug in uvesafb and I should have contacted Michal Januszewski
("spock") directly, because he is the original writer of uvesafb. By the
way - he is not listed in the MAINTAINERS file - is this driver
currently not maintained by anyone?
On the other hand, my problem has been introduced by this somewhat lower
level HR timer patch, so maybe Peter would have been the right person to
hit on.

I have decided to let you decide however. :P


Here is some other information which could be useful:

[ 0.292261] uvesafb: NVIDIA Corporation, NV34 Board - p164-2n , Chip
Rev , OEM: NVIDIA, VBE v3.0
[ 0.301472] uvesafb: protected mode interface info at c000:e340
[ 0.301544] uvesafb: pmi: set display start = c00ce376, set palette =
c00ce3e0
[ 0.301641] uvesafb: pmi: ports = 3b4 3b5 3ba 3c0 3c1 3c4 3c5 3c6 3c7
3c8 3c9 3cc 3ce 3cf 3d0 3d1 3d2 3d3 3d4 3d5 3da
[ 0.304337] uvesafb: VBIOS/hardware supports DDC2 transfers
[ 0.344795] Display is GTF capable
[ 0.344895] uvesafb: monitor limits: vf = 200 Hz, hf = 132 kHz, clk =
350 MHz
[ 0.345249] uvesafb: scrolling: ywrap using protected mode interface,
yres_virtual=4915
[ 0.744920] Switched to high resolution mode on CPU 0
[ 0.847204] Console: switching to colour frame buffer device 160x64
[ 0.893878] uvesafb: framebuffer at 0xd0000000, mapped to 0xf8880000,
using 24576k, total 262144k
[ 0.894386] fb0: VESA VGA frame buffer device

The first bad Kernel version I have in use is:

Linux version 2.6.24-OSS4-GIT-Regress-Test-g8f4d37ec-dirty (root@deff)
(gcc version 4.1.2 20070214 ( (gdc 0.24, using dmd 1.020)) (Gentoo 4.1.2
p1.0.2)) #2 PREEMPT Sat Jul 5 10:42:18 CEST 2008

I have applied a custom patch as well - BadRAM. But I think this ought
not interfere with uvesafb.

Relevant sections of my config file are:

CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPT_RCU is not set
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_BKL=y
# CONFIG_DEBUG_PREEMPT is not set
CONFIG_FB_UVESA=y
CONFIG_SCHED_HRTICK=y
CONFIG_NO_HZ=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_HIGH_RES_TIMERS=y

If you need any other information, please to *not* hesitate to ask. The
information I have provided now are only those I thought they could be
usable.


Also, I want to ask any other uvesafb user to test this and confirm the
bug (if it can be confirmed, of course...)

I have also tested the newest RC kernel (2.6.26-rc9) which faces the
same problems.



I hope this was all correctly and I have not broken any rule or missed
anything.


At the last thing, I want to personally thank Linus and all the other
Kernel Hackers for the so far good work. Keep going! :)


Have a nice afternoon (in Europe),


Best regards,



Mihai "Ionic" Moldovan






P.S.: what is the status about BadRAM? Will it get into Mainline soon?
AFAIK it is pending since Feb 08 and I would really like to see it
included. :)


\
 
 \ /
  Last update: 2008-07-07 19:29    [W:0.076 / U:1.540 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site